Graphing weather data
Locked
12
12
 
|
> On 24-12-2016, at 2:37 PM, Chris Muller <[hidden email]> wrote: > http://www.squeaksource.com/PlotMorph/ Looks good, the PlotMorph class>test# examples look nice, the StackedPlotMorph example fails because of missing PlotMorph class>example# methods and as with almost all our code, could do with some explanations & comments. > > You should use Magma for any Squeak data project. Its by far the safest way to keep your objects. I look forward to trying it. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Gargoyle (n.), Popeye’s olive-flavored mouthwash. |
Re: Backward image and VM compatibility
|
|
In reply to this post by David T. Lewis
On Wed, Dec 21, 2016 at 06:53:42PM -0500, David T. Lewis wrote:
> > On Wed, Dec 21, 2016 at 06:17:55PM -0500, Bob Arning wrote: > > > > On 12/21/16 5:56 PM, David T. Lewis wrote: > > > > > > On Wed, Dec 21, 2016 at 05:15:29PM -0500, Bob Arning wrote: > > > > > > > > On 12/21/16 11:38 AM, David T. Lewis wrote: > > > > > > > > > > Following up on this, the backward compatibility for interpreter VM supporting > > > > > old images was broken in VMMaker-dtl.387 of 8 November 2016, due to my attempt > > > > > to align the primitive table closer to Cog/Spur: > > > > > > > Is there a specific oldest image which current VMs are expected to run? > > > > > > > A current interpreter VM should run a Squeak 3.2 image, although with some > > > problems. It should be able to run images from the Squeak 3.6 and 3.8 era > > > without problems. And it should run anything else up to but not including > > > Spur. > > > > > Is the current interpreter VM (for the mac) one of the ones on > > http://www.squeakvm.org/mac/? I'm not clear how to parse the names of > > things into what they can or cannot do. > > > > I am referring specifically to an interpreter VM that you might build from the > latest updated sources according to this recipe: > > http://wiki.squeak.org/squeak/6354 > > That is not very helpful if you are on a Mac, sorry for that. I think that > it may work on Mac if you have the X11 support installed, but I am not in > a position to verify it. > > The squeakvm.org site is getting out of date, although Ian Piumarta said > in private email that he would welcome constructive input to bring it up > to date, and possibly to update the interpreter VM builds if there is some > general interest in doing so. > Since my reply above from last month, the interpreter VM has been updated based on logic borrowed from the SqueakJS VM, and it can now run images back to Squeak 1.13 and up to Squeak 4.6. The caveats are that you have to compile it yourself (see above) and it has only been tested on Linux. "PluckedSound backFugue play" now works nicely in Squeak 1.13 on Ubuntu, so that is an encouraging sign. It might work on OS X with X11 installed, but I have not tried. The interpreter VM cannot run the newer Spur images, although SqueakJS is able to do so. I do not anticipate that the interpreter VM will support Spur images, since the Cog/Spur VMs already do this very well. Dave |
Re: Backward image and VM compatibility
|
|
On Thu, Jan 5, 2017 at 4:04 AM, David T. Lewis <[hidden email]> wrote:
Awesome! "PluckedSound backFugue play" now works nicely in Squeak 1.13 on Ubuntu, so When I try this in SqueakJS the sound seems very high-pitched. Is this the case in your VM, too? Maybe it used a different sample rate back then? - Bert - |
Re: Backward image and VM compatibility
|
|
On Fri, Jan 06, 2017 at 03:19:33PM +0100, Bert Freudenberg wrote:
> On Thu, Jan 5, 2017 at 4:04 AM, David T. Lewis <[hidden email]> wrote: > > > > > Since my reply above from last month, the interpreter VM has been updated > > based > > on logic borrowed from the SqueakJS VM, and it can now run images back to > > Squeak 1.13 and up to Squeak 4.6. The caveats are that you have to compile > > it yourself (see above) and it has only been tested on Linux. > > > > Awesome! > > > > "PluckedSound backFugue play" now works nicely in Squeak 1.13 on Ubuntu, so > > that is an encouraging sign. > > > > When I try this in SqueakJS the sound seems very high-pitched. Is this the > case in your VM, too? Maybe it used a different sample rate back then? > The pitch and durations sound the same to me. I tried running the fugue on a 1.13 image and a 4.6 image at the same time. It produces an audio experience that Bach could never have anticipated, but the pitches are the same and the dueling Squeaks end their performances at about the same time. This is Linux pulse audio on a laptop with tiny speakers. Dave |
PulseAusdio (was: Re: Backward image and VM compatibility)
|
|
> On 06-01-2017, at 6:55 AM, David T. Lewis <[hidden email]> wrote: > > This is Linux pulse audio on a laptop with tiny speakers. So PA with the older vm is generally OK? Maybe that might help us work out why it is a problem with cog/spur/threadedHB. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Science adjusts its views based on what is observed. Faith denies observation so belief can be preserved |
Re: PulseAusdio (was: Re: Backward image and VM compatibility)
|
|
>
>> On 06-01-2017, at 6:55 AM, David T. Lewis <[hidden email]> wrote: >> >> This is Linux pulse audio on a laptop with tiny speakers. > > So PA with the older vm is generally OK? Maybe that might help us work out > why it is a problem with cog/spur/threadedHB. > > tim > -- It seems fine to me, although I can't say that I exercised it very heavily. I just loaded the libpulse-dev libraries about a day or two ago for the first time in I don't remember when, but it worked fine as soon as I tried it. You might try running without the threaded heartbeat and see if the symptoms change. Dave |
Re: Backward image and VM compatibility
|
|
In reply to this post by David T. Lewis
On Fri, Jan 06, 2017 at 09:55:28AM -0500, David T. Lewis wrote:
> On Fri, Jan 06, 2017 at 03:19:33PM +0100, Bert Freudenberg wrote: > > On Thu, Jan 5, 2017 at 4:04 AM, David T. Lewis <[hidden email]> wrote: > > > > > > > > Since my reply above from last month, the interpreter VM has been updated > > > based > > > on logic borrowed from the SqueakJS VM, and it can now run images back to > > > Squeak 1.13 and up to Squeak 4.6. The caveats are that you have to compile > > > it yourself (see above) and it has only been tested on Linux. > > > > > > > Awesome! > > > > > > > "PluckedSound backFugue play" now works nicely in Squeak 1.13 on Ubuntu, so > > > that is an encouraging sign. > > > > > > > When I try this in SqueakJS the sound seems very high-pitched. Is this the > > case in your VM, too? Maybe it used a different sample rate back then? > > > > The pitch and durations sound the same to me. I tried running the fugue on > a 1.13 image and a 4.6 image at the same time. It produces an audio experience > that Bach could never have anticipated, but the pitches are the same and the > dueling Squeaks end their performances at about the same time. > > This is Linux pulse audio on a laptop with tiny speakers. > Bert, I have to apologize, the information I gave you above is wrong. I was running the bachFugue on a Squeak 1.31 image, not a Squeak 1.13u image. I confirm your high pitch symptoms for Squeak 1.13u on SqueakJS, but I am not able to test 1.13u on the interpreter VM. It runs and browsers work, but I cannot evaluate an expression in a workspace. This seems to be the case for images earlier than Squeak 1.31 so something is still broken for the interpreter VM for Squeak 1.23 and earlier. The issue seems to be related to something that changed between Squeak 1.23 and Squeak 1.31. Sound issues aside, if you want to do any serious work on a Squeak 1.13u image I still recommend using SqueakJS :-) Sorry for the misinformation. Dave |
Re: Backward image and VM compatibility
|
|
On Sat, Jan 7, 2017 at 12:58 AM, David T. Lewis <[hidden email]> wrote:
Some of the early images are missing UnixFileDirectory so SqueakJS has a mode for emulating Mac file names: But "1.13u" should be one of Ian's images which include this class so I'm not so sure what changed between that and 1.31 ... - Bert - |
Re: Backward image and VM compatibility
|
|
On Tue, Jan 10, 2017 at 11:59:18AM +0100, Bert Freudenberg wrote:
> On Sat, Jan 7, 2017 at 12:58 AM, David T. Lewis <[hidden email]> wrote: > > > > > I confirm your high pitch symptoms for Squeak 1.13u on SqueakJS, but I am > > not > > able to test 1.13u on the interpreter VM. It runs and browsers work, but I > > cannot evaluate an expression in a workspace. This seems to be the case for > > images earlier than Squeak 1.31 so something is still broken for the > > interpreter > > VM for Squeak 1.23 and earlier. The issue seems to be related to something > > that > > changed between Squeak 1.23 and Squeak 1.31. > > > > Sound issues aside, if you want to do any serious work on a Squeak 1.13u > > image > > I still recommend using SqueakJS :-) > > > > Some of the early images are missing UnixFileDirectory so SqueakJS has a > mode for emulating Mac file names: > https://github.com/bertfreudenberg/SqueakJS/search?q=emulateMac > > But "1.13u" should be one of Ian's images which include this class so I'm > not so sure what changed between that and 1.31 ... Thanks Bert. It appears to be something related to MethodContext. Since it is VM related, I initially guessed that it might be something related to the method cache, but I was able to disable that in the VM and the symptoms did not change. I'm thinking now that it might be a failure in primitive 61 when trying to copy a MethodContext, this based on the debugger stack (although I cannot actually display anything useful in the debugger). I'll report back if I end up figuring it out, meanwhile any and all historical clues are appreciated :-) Dave |
Re: Backward image and VM compatibility
|
|
On Tue, Jan 10, 2017 at 3:13 PM, David T. Lewis <[hidden email]> wrote:
Ah, slowly all the hacks I had to put in are coming back to me ;) Some early images fill the context stack before advancing its stack pointer. I have a flag to allow that, it's pretty certainly used in primitive 61. Normally the VM does not allow access beyond the SP because there is garbage there (stack pops do not nil out the context slot): But since the regular VM does not allow it, no image (except the really old ones) ever does it, so I just leave the flag enabled whenever "oldPrims" is in effect ;) Would be better if we could come up with a better way to identify these images. - Bert - |
Re: Backward image and VM compatibility
|
|
On Wed, Jan 11, 2017 at 05:10:24PM +0100, Bert Freudenberg wrote:
> On Tue, Jan 10, 2017 at 3:13 PM, David T. Lewis <[hidden email]> wrote: > > > > > Thanks Bert. It appears to be something related to MethodContext. Since it > > is VM related, I initially guessed that it might be something related to > > the method cache, but I was able to disable that in the VM and the symptoms > > did not change. I'm thinking now that it might be a failure in primitive 61 > > when trying to copy a MethodContext, this based on the debugger stack > > (although I cannot actually display anything useful in the debugger). > > > > I'll report back if I end up figuring it out, meanwhile any and all > > historical > > clues are appreciated :-) > > > > Ah, slowly all the hacks I had to put in are coming back to me ;) > > Some early images fill the context stack before advancing its stack > pointer. I have a flag to allow that, it's pretty certainly used in > primitive 61. Normally the VM does not allow access beyond the SP because > there is garbage there (stack pops do not nil out the context slot): > > https://github.com/bertfreudenberg/SqueakJS/search?q=allowAccessBeyondSP > > But since the regular VM does not allow it, no image (except the really old > ones) ever does it, so I just leave the flag enabled whenever "oldPrims" is > in effect ;) Would be better if we could come up with a better way to > identify these images. > Brilliant, thanks Bert. I see several places where we check "fmt = 3 and: [self isContextHeader: hdr]", including in #stObject:at:put: which is probably the immediate cause of the failure that I was seeing. And #stSizeOf: does this: (fmt = 3 and: [self isContextHeader: hdr]) ifTrue: [stSize := self fetchStackPointerOf: array] ifFalse: [stSize := totalLength - fixedFields]. I'll try playing with it this weekend and see if I can get it working for the older images. But I have to ask ... how in the world did you figure this out? :-) Dave |
Re: Backward image and VM compatibility
|
|
On Wed, Jan 11, 2017 at 09:03:53PM -0500, David T. Lewis wrote:
> On Wed, Jan 11, 2017 at 05:10:24PM +0100, Bert Freudenberg wrote: > > On Tue, Jan 10, 2017 at 3:13 PM, David T. Lewis <[hidden email]> wrote: > > > > > > > > Thanks Bert. It appears to be something related to MethodContext. Since it > > > is VM related, I initially guessed that it might be something related to > > > the method cache, but I was able to disable that in the VM and the symptoms > > > did not change. I'm thinking now that it might be a failure in primitive 61 > > > when trying to copy a MethodContext, this based on the debugger stack > > > (although I cannot actually display anything useful in the debugger). > > > > > > I'll report back if I end up figuring it out, meanwhile any and all > > > historical > > > clues are appreciated :-) > > > > > > > Ah, slowly all the hacks I had to put in are coming back to me ;) > > > > Some early images fill the context stack before advancing its stack > > pointer. I have a flag to allow that, it's pretty certainly used in > > primitive 61. Normally the VM does not allow access beyond the SP because > > there is garbage there (stack pops do not nil out the context slot): > > > > https://github.com/bertfreudenberg/SqueakJS/search?q=allowAccessBeyondSP > > > > But since the regular VM does not allow it, no image (except the really old > > ones) ever does it, so I just leave the flag enabled whenever "oldPrims" is > > in effect ;) Would be better if we could come up with a better way to > > identify these images. > > > > Brilliant, thanks Bert. > > I see several places where we check "fmt = 3 and: [self isContextHeader: hdr]", > including in #stObject:at:put: which is probably the immediate cause of the > failure that I was seeing. And #stSizeOf: does this: > > (fmt = 3 and: [self isContextHeader: hdr]) > ifTrue: [stSize := self fetchStackPointerOf: array] > ifFalse: [stSize := totalLength - fixedFields]. > > I'll try playing with it this weekend and see if I can get it working for the > older images. > > But I have to ask ... how in the world did you figure this out? > > :-) > Indeed, disabling the stack pointer check in #stObject:at:put: results in a VM that now works with the old Squeak1.13u.image. Dave |
Re: Backward image and VM compatibility
|
|
On Thu, Jan 12, 2017 at 12:56 PM, David T. Lewis <[hidden email]> wrote:
Well, debugging the startup code is actually quite comfortable using my VM debugger (https://lively-web.org/users/ So what I did is pause the VM when the startup didn't finish, look up the call stack to see where things went wrong, set a break point for that method, run again, and then single-step to where it goes wrong. At least I think that's what I did, because right now I can't get it to malfunction even when I disable the flag ... where exactly did it break for you?
Yay! :) - Bert - |
Re: Backward image and VM compatibility
|
|
>> > >> > But I have to ask ... how in the world did you figure this out? >> > > Well, debugging the startup code is actually quite comfortable using my VM > debugger (https://lively-web.org/users/bert/squeak.html). It shows the > call > stack, current frame, and byte code, and lets you set a break point, and > single-step through the code. Someone should make a similar UI for the > Squeak VM Simulator :) > > So what I did is pause the VM when the startup didn't finish, look up the > call stack to see where things went wrong, set a break point for that > method, run again, and then single-step to where it goes wrong. > > At least I think that's what I did, because right now I can't get it to > malfunction even when I disable the flag ... where exactly did it break > for you? > The image runs and browsers work normally. But open a workspace and evaluate "2 + 2" and you will see the error. Dave |
Re: Backward image and VM compatibility
|
|
In reply to this post by Bob Arning-2
On Wed, Dec 21, 2016 at 05:15:29PM -0500, Bob Arning wrote:
> > Is there a specific oldest image which current VMs are expected to run? > Here is a summary of what I get when running a range of historical images on an interpreter VM on Linux. This is verified only on Linux with the unix VM and probably does not apply to other platforms. It requires recompiling the VM to get a current version (http://wiki.squeak.org/squeak/6354). Year Image Status 1996 Squeak1.1.image Does not work, white screen. 1996 Squeak1.13u.image Runs well, but cannot resize main window, and "AbstractSound bachFugue play" locks up the image 1996 Squeak1.16u.image Runs well, but cannot resize main window, and "PluckedSound bachFugue play" locks up the image 1996 Squeak1.17u.image Runs well, but cannot resize main window, and "PluckedSound bachFugue play" locks up the image 1996 Squeak1.18.image Runs well, but cannot resize main window, and "PluckedSound bachFugue play" locks up the image 1997 Squeak1.22.image Runs well, but cannot resize main window, and "PluckedSound bachFugue play" locks up the image 1997 Squeak1.23.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works, sound not as good as later images 1997 Squeak1.23up.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works, sound not as good as later images 1998 Squeak1.31.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works well 1998 Squeak2.0.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works well 1998 Squeak2.1.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works well 1998 Squeak2.3.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works well 1999 Squeak2.4c.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works well 1999 Squeak2.5.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works well 1999 Squeak2.6.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works well 2000 Squeak2.7.image Runs well, but cannot resize main window. "PluckedSound bachFugue play" works well 2000 Squeak2.8.image Runs well, main window resize crashes VM, "PluckedSound bachFugue play" works well 2001 Squeak3.0.image Runs well, main window resize OK, sound OK. 2015 Squeak4.6-15102.image Runs well 2017 status: Runs any V3 image. No Spur support, cannot run trunk. Necessary primitives have been added such that "trunk level" V3 works (system reporter reports for "trunk level" V3 images below). 32 bit image / 64 bit VM: Image ----- /home/lewis/squeak/Squeak4.6/squeak.122.image Squeak6.0alpha latest update: #16892 Current Change Set: Follow Trunk on V3 Image format 6504 (32 bit) Virtual Machine --------------- /usr/local/lib/squeak/4.16.3-3748/squeakvm Squeak4.5 of 10 December 2015 [latest update: #1195] Unix built on Jan 13 2017 19:03:05 Compiler: 4.9.2 platform sources revision 3748 VMMaker versionString 4.16.3 64 bit image / 64 bit VM: Image ----- /home/lewis/squeak/Squeak4.6/squeak.122-64.image Squeak6.0alpha latest update: #16892 Current Change Set: Follow Trunk on V3 Image format 68002 (64 bit) Virtual Machine --------------- /usr/local/lib/squeak/4.16.3-3748_64bit/squeakvm64 Squeak4.5 of 10 December 2015 [latest update: #1195] Unix built on Jan 13 2017 19:03:42 Compiler: 4.9.2 platform sources revision 3748 VMMaker versionString 4.16.3 -Dave |
|
|
In reply to this post by timrowledge
Hey Tim
> On 25.12.2016, at 00:23, tim Rowledge <[hidden email]> wrote: > > >> On 24-12-2016, at 2:37 PM, Chris Muller <[hidden email]> wrote: >> http://www.squeaksource.com/PlotMorph/ > > Looks good, the PlotMorph class>test# examples look nice, the StackedPlotMorph example fails because of missing PlotMorph class>example# methods and as with almost all our code, could do with some explanations & comments. What about putting that into trunk or so? Best regards -Tobias > > >> >> You should use Magma for any Squeak data project. Its by far the safest way to keep your objects. > > I look forward to trying it. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Gargoyle (n.), Popeye’s olive-flavored mouthwash. > > > |
|
|
+1 for adding it to MorphicExtras
--Hannes On 6/20/17, Tobias Pape <[hidden email]> wrote: > Hey Tim > >> On 25.12.2016, at 00:23, tim Rowledge <[hidden email]> wrote: >> >> >>> On 24-12-2016, at 2:37 PM, Chris Muller <[hidden email]> wrote: >>> http://www.squeaksource.com/PlotMorph/ >> >> Looks good, the PlotMorph class>test# examples look nice, the >> StackedPlotMorph example fails because of missing PlotMorph class>example# >> methods and as with almost all our code, could do with some explanations & >> comments. > > What about putting that into trunk or so? > > Best regards > -Tobias > >> >> >>> >>> You should use Magma for any Squeak data project. Its by far the safest >>> way to keep your objects. >> >> I look forward to trying it. >> >> tim >> -- >> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >> Gargoyle (n.), Popeye’s olive-flavored mouthwash. >> >> >> > > > |
|
|
> On 29-06-2017, at 2:11 PM, H. Hirzel <[hidden email]> wrote: > > +1 for adding it to MorphicExtras You should now find it as of MorphicExtras-tpr.208.mcz tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Oxymorons: Airline Food |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |