[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] Strange behavior while editing/running scripts/Novice



> >I am learning MacPerl and have been having a problem I can't solve. When I
> >edit scripts, save and run them often an old version (not loaded) will run
> >without any of my new edits. This can happen even if I quit MacPerl and
> >restart loading the new script. Is there something simple I am missing?
>
> Hi
>
> I managed to do this once also. Mac files have to parts, the data and the
> resource fork. The data fork typically holds the text if it's a file saved
> from a wordprocessor or it holds the code for PowerPC programs (ordinary
> programs like Word or MacPerl, not the ones you write with perl). The
> resorcefork holds code for 68K programs, icons, sound and pictures etc.
> Then you save a plain textfile in perl you get the text in the datafork and
> the resource fork is empty. But then you save droplets the program code and
> little programcode is written to the resource fork. The little code is just
> enough to run the droplet and send the program text to MacPerl for
> evaluation. So what I am trying to say with this rather lenghty explanation
> is that there seems to be a bug in MacPerl which makes it possible to save
> a perlprogram as a textfile first and later a droplet (or the other way
> around) and it doesn't remove the parts in the other fork as it should. So
> you then you selects "Run scriptÉ" in the menu and you belive you have a
> textfile which should run, MacPerl sees the leftover parts in the resource
> fork and runs them instead.
>
> Hope this helps, Johan Dahl

I am not saving as runtime or droplet only as plain text from MacPerl
editor then running by typing shift-command-R (runs script in frontmost
window). Viewing the debugger and output I can tell the wrong version (that
no longer exists anywhere I have saved it) is running. Occasionally the
correct version will execute but it sure is lengthening the development
process :-) This occurs >95% of the time.

Did you develop a solution around your problem? (this is version 5.0.7r1m)