Graphing weather data

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Graphing weather data

timrowledge

> 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.



Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

Bert Freudenberg
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?

- Bert - 



Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

PulseAusdio (was: Re: Backward image and VM compatibility)

timrowledge

> 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


Reply | Threaded
Open this post in threaded view
|

Re: PulseAusdio (was: Re: Backward image and VM compatibility)

David T. Lewis
>
>> 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



Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

David T. Lewis
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
 

Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

Bert Freudenberg
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:

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 - 

 



Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

Bert Freudenberg
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):


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 -
 


Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

Bert Freudenberg
On Thu, Jan 12, 2017 at 12:56 PM, David T. Lewis <[hidden email]> wrote:
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:
> >
> > 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.
>
> 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?

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?
 
> :-)
>

Indeed, disabling the stack pointer check in #stObject:at:put: results in
a VM that now works with the old Squeak1.13u.image

Yay! :)

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

David T. Lewis


>> >
>> > 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






Reply | Threaded
Open this post in threaded view
|

Re: Backward image and VM compatibility

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Graphing weather data

Tobias Pape
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.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Graphing weather data

Hannes Hirzel
+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.
>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Graphing weather data

timrowledge

> 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



12