| | <<<Back 1 day (to 2012/06/23) | 2012/06/24 |
| Robin_Watts | sebras: Thanks. I'll look on monday. Just going to bed now, and tomorrow is going to be busy. | 00:05.46 |
| sebras | Robin_Watts: ah, no problem. :) | 07:58.38 |
| nlogax | I'm trying to turn a PS library into a proper resource, but having trouble finding some noob-friendly examples. If i begin with just moving it to its own file, creating a dict and `defineresource'ing it, I get it working with `/foo /ProcSet findresource { def } forall', which is gross obviously | 09:07.36 |
| | When I try to fix it up I come across lots of /invalidaccess, and I'm wondering how I can have e.g a "shared" dictionary, used within the library, and writable for users using said library. | 09:08.48 |
| chrisl_away | nlogax: it looks to me like your use of the procset is wrong | 10:38.46 |
| nlogax | chrisl_away: How so? I mean, other than the `... { def } forall' bit :) | 10:45.15 |
| chrisl_away | nlogax: a ProcSet is really just a dictionary, and findresource just pushed the dictionary onto the operand stack. | 10:54.42 |
| | So, normally, if you just want to call one procedure, you'd do something like: "/MyProcSet /ProcSet findresource /MyProcedure get exec" | 10:55.43 |
| | Or, if you're going to be doing more stuff with PS that assumes the ProcSet procedures are defined, you'd do: | 10:56.53 |
| | /MyProcSet /ProcSet findresource begin | 10:56.55 |
| | % Do all my special Postscript...... | 10:56.57 |
| | end | 10:56.59 |
| | nlogax: Actually, thinking about it, a better version of the above would be: | 10:58.48 |
| nlogax | chrisl_away: Yes, so far so good. But my problem, which I explained very poorly, is when I call a procedure from the ProcSet, which in turn attempts to modify a dict defined in the ProcSet file | 10:59.00 |
| | chrisl_away: And then throws invalidaccess | 10:59.25 |
| chrisl_away | Well obviously, once defined as a resource, a ProcSet dictionary is read-only | 10:59.56 |
| | nlogax: do this: | 11:00.43 |
| | /MyProcSet /ProcSet findresource begin | 11:00.45 |
| | 10 dict begin % arbitrary sized working dictionary | 11:00.47 |
| | % Do all my special Postscript...... | 11:00.49 |
| | end | 11:00.51 |
| nlogax | In the ProcSet I have the equivalent of: /somedict << >> def /someproc { do something with somedict } bind def . When /someproc is called (from the outside), I want to keep some state in /somedict. Is that the wrong way to go about it? | 11:01.37 |
| chrisl_away | Yes, that's wrong, you can't do that | 11:02.01 |
| nlogax | Ok, thanks :) Then I'll try to do it another way | 11:02.57 |
| chrisl_away | Personally, I wouldn't use a ProcSet for that, *but* if you really want to, you could store your "state" dictionary in userdict, with a reasonably weird name, so it wouldn't be in danger of getting overwritten | 11:04.11 |
| nlogax | I'll try that, thank you. Would it make sense to instead have some sort of `initialize' procedure, that would set up things like that? | 11:06.12 |
| chrisl_away | Hmm, I don't know if you can have a ProcSet do that on instantiation (it's a while since I worked in that area), you could certainly have a procedure in the ProcSet which should be called before it's used. | 11:08.23 |
| | nlogax: I think what I would do would be to have procedure in the ProcSet "InitWorkingDict" or something, which *very* procedure calls before doing anything - and "InitWorkingDict" would first check if the "special" dictionary already exists in userdict, if not creates it, and then pushed it onto the operand stack, ready to be pushed onto the dictionary stack with a "begin". | 11:11.12 |
| | s/*very*/*every* | 11:11.30 |
| | So every procedure in your ProcSet would have the form: | 11:13.07 |
| | /MyProc | 11:13.09 |
| | { | 11:13.11 |
| | InitWorkingDict begin | 11:13.13 |
| | %% do all my clever PS | 11:13.15 |
| | end | 11:13.17 |
| | } bind def | 11:13.18 |
| nlogax | Would it be bad style to require that the user call a certain procedure, which sets up all the bookkeeping statey stuff? | 11:15.52 |
| | Though I doubt this will ever be used by someone other than me anyway :D | 11:16.13 |
| chrisl_away | Hmm, that's a personal choice, I would say. I'd do it the way I described above because, even if I was the only person to use it, I *know* I would forget to call the setup proc, and it would end up p*ssing me off! | 11:19.20 |
| nlogax | Hahhaa, that's true. | 11:20.04 |
| chrisl_away | I don't believe there a convention covering that kind of thing, though | 11:20.58 |
| | I have to go - good luck! I'll be around tomorrow, if you have more questions.... | 11:21.43 |
| nlogax | All right, thanks for the help! | 11:23.11 |
| vtorri | hey | 11:46.28 |
| ghostbot | hi, vtorri | 11:46.29 |
| vtorri | did mupdf API change a lot between 0.9 and 1.0 ? | 11:46.53 |
| Robin_Watts | vtorri: yes | 11:55.37 |
| | In that lots of APIs changed, but all in a fairly consistent way (adding context params) | 11:56.00 |
| | it's not that big of a search/replace thing to fix. | 11:56.11 |
| nlogax | chrisl_away: Oh, now I think I at least understand why it isn't working. It *does* work with "primitive" values, but not with procedures and whatnot. Just read about local/global VM, so it must be that the internal dict cannot contain a reference to a proc in local VM. | 11:58.43 |
| vtorri | Robin_Watts: thank you | 12:02.09 |
| | Robin_Watts: is 1.0 considered as stable ? | 12:02.32 |
| sebras | vtorri: that was the intention with the 1.0 release. | 12:57.43 |
| vtorri | good :) | 12:57.59 |
| sebras | vtorri: I haven't kept track of whether there has been any interface changes between 1.0 and now though. | 12:58.04 |
| vtorri | so will shared lib be available with the build process , | 12:58.15 |
| sebras | vtorri: no, there's no shared lib being built yet. | 12:59.04 |
| vtorri | later ? or never ? | 13:00.39 |
| | because, iirc, tor mentioned he didn't shared lib because of the API not being stable | 13:01.02 |
| sebras | vtorri: I don't know, I believe tor will need to be back for a decision on this. | 13:01.43 |
| vtorri | sure | 13:02.14 |
| sebras | vtorri: however there is a GTK+ app in the works, so I wouldn't be surprised if this means that shared libraries are suddenly required. but I haven't really looked at that development branch. | 13:04.00 |
| vtorri | i'm writing one with another toolkit | 13:27.07 |
| | Forward 1 day (to 2012/06/25)>>> | |
IRC Logs