new Cog VMs uploaded

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

new Cog VMs uploaded

Eliot Miranda-2
...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale plugin.

best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

garduino
2011/4/26 Eliot Miranda <[hidden email]>:
> ...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix
> shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale
> plugin.
> best,
> Eliot

Downloading.

Thanks!

--
=================================================
Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
Arduino Software & Web Hosting   http://www.arduinosoftware.com
PasswordsPro  http://www.passwordspro.com
=================================================
Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Scott Gibson
In reply to this post by Eliot Miranda-2
I have been using and developing with it for the Mac OS.  Thanks Eliot!

Scott Gibson

On Apr 26, 2011, at 5:01 PM, Eliot Miranda wrote:

...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale plugin.

best,
Eliot


--
Scott Gibson


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
with a fix for the VMs in 2379 to http://www.mirandabanda.org/files/Cog/VM/VM.r2380/.  These pass Levente's shift/reset tests.  Apologies for the earlier slip.

On Tue, Apr 26, 2011 at 2:01 PM, Eliot Miranda <[hidden email]> wrote:
...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale plugin.

best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Philippe Marschall-2-3
In reply to this post by Eliot Miranda-2
On 26.04.2011 23:01, Eliot Miranda wrote:
> ...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix
> shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale
> plugin.

The following still crashes my vm:

(Locale localeID: (LocaleID isoLanguage: 'de' isoCountry: 'CH'))
primShortDateFormat

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Philippe Marschall-2-3
In reply to this post by Eliot Miranda-2
On 26.04.2011 23:01, Eliot Miranda wrote:
> ...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix
> shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale
> plugin.

I'm seeing quite a drastic performance degradation in the last two Cog
releases for Seaside. r2361 and r2370 would yield about 4300 to 4400
"points" for /tests/functional/WAPerformanceFunctionalTest. r2378 and
r2380 are down to about 2600 to 2700. That's almost a third slower.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Eliot Miranda-2
Philippe,

    can you please profile before and after?  This could very well be to do with the additional cost of shallowCopy for contexts, but it is inevitable that a correct implementation is going to be more expensive than the simple block-copy.  The new implementation can be optimized, but we need to profile first to be sure we're tilting at the relevant windmill.

AdvThanksance
Eliot

On Wed, Apr 27, 2011 at 9:40 AM, Philippe Marschall <[hidden email]> wrote:
On <a href="tel:26.04.2011%2023" value="+12604201123">26.04.2011 23:01, Eliot Miranda wrote:
> ...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix
> shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale
> plugin.

I'm seeing quite a drastic performance degradation in the last two Cog
releases for Seaside. r2361 and r2370 would yield about 4300 to 4400
"points" for /tests/functional/WAPerformanceFunctionalTest. r2378 and
r2380 are down to about 2600 to 2700. That's almost a third slower.

Cheers
Philippe



Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Eliot Miranda-2
In reply to this post by Philippe Marschall-2-3
can you post a stack trace from gdb?  Also, what linux system and what image are you using?

TIA
Eliot

On Wed, Apr 27, 2011 at 8:18 AM, Philippe Marschall <[hidden email]> wrote:
On <a href="tel:26.04.2011%2023" value="+12604201123">26.04.2011 23:01, Eliot Miranda wrote:
> ...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix
> shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale
> plugin.

The following still crashes my vm:

(Locale localeID: (LocaleID isoLanguage: 'de' isoCountry: 'CH'))
primShortDateFormat

Cheers
Philippe



Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Eliot Miranda-2
In reply to this post by Philippe Marschall-2-3
Hi All,

    this is because of carelessness in the trunk platforms/unix/plugins/LocalePlugin/sqUnixLocale.c which uses strcpy to copy C strings from the locale subsystem into Smalltalk strings.  strcpy copies the trailing null, which will overwrite the first byte of the following object.  This just happens not to kill the standard VM because current code always uses these functions on new strings.  But Cog currently checks for attempts to overwrite objects and hence it catches these attemptys and aborts, with an error message.

Hilaire, Phillipe, you should have seen and reported the "last object overwritten" report form the VM and if so we would have debugged this a lot sooner.  Error messages are there to be read. 

Ian, David, I recommend that you fold

    Revision: 2382

back into trunk.

I've replaced all uses of strcpy in platforms/unix/plugins/LocalePlugin/sqUnixLocale.c with the following:

/* For Cog do *not* copy the trailing null since the VM checks for attempts to
 * overwrite the end of an object, and copying the trailing null into a string
 * does precisely this.
 */
#define safestrcpy(str,source) do { \
    char *src = (source); \
    int len = strlen(src); \
    strncpy(str,src,len); \
} while (0)



On Wed, Apr 27, 2011 at 8:18 AM, Philippe Marschall <[hidden email]> wrote:
On <a href="tel:26.04.2011%2023" value="+12604201123">26.04.2011 23:01, Eliot Miranda wrote:
> ...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix
> shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale
> plugin.

The following still crashes my vm:

(Locale localeID: (LocaleID isoLanguage: 'de' isoCountry: 'CH'))
primShortDateFormat

Cheers
Philippe



Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
and now http://www.mirandabanda.org/files/Cog/VM/VM.r2382/ has the fix for Locale on linux.

On Tue, Apr 26, 2011 at 6:37 PM, Eliot Miranda <[hidden email]> wrote:
with a fix for the VMs in 2379 to http://www.mirandabanda.org/files/Cog/VM/VM.r2380/.  These pass Levente's shift/reset tests.  Apologies for the earlier slip.


On Tue, Apr 26, 2011 at 2:01 PM, Eliot Miranda <[hidden email]> wrote:
...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/.  These fix shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale plugin.

best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Henrik Sperre Johansen
In reply to this post by Eliot Miranda-2
Also note, primShortDateFormat does nothing with the Locale you specify.

All the primitives return values for the current process locale. (Set at startup to system locale rather than C)

You'd need to forcibly change the process locale with primSetLocale from ImmX11Plugin (which isn't available in the image, thank God), and hope your linux has that locale installed
(Ubuntu f.ex. only comes with a single one installed by default, and switching to anything but that or C will fail)

Can't use primGetLocale (not accessible from image either :D ) to check if it's been successful though, as that resets the locale to system locale :)

TLDR; What you want to do is impossible with the current implementation.
Correcting it is really a waste of time, as something which works correct would be shabby at best.
Implementing use of CLDR data is the way to go if you want something that is both reliable and works.

The only bits the Locale plugin is good at (should be used for), is getting the system defined country/language.

Cheers,
Henry
Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Henrik Sperre Johansen
In reply to this post by Eliot Miranda-2
Don't tell me you didn't have an idea this would happen :)
Or was it Igor I talked to it about in Lille?
Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Henrik Sperre Johansen
In reply to this post by Henrik Sperre Johansen
On 27.04.2011 20:35, Henrik Sperre Johansen wrote:

> Also note, primShortDateFormat does nothing with the Locale you specify.
>
> All the primitives return values for the current process locale. (Set at
> startup to system locale rather than C)
>
> You'd need to forcibly change the process locale with primSetLocale from
> ImmX11Plugin (which isn't available in the image, thank God), and hope your
> linux has that locale installed
> (Ubuntu f.ex. only comes with a single one installed by default, and
> switching to anything but that or C will fail)
>
> Can't use primGetLocale (not accessible from image either :D ) to check if
> it's been successful though, as that resets the locale to system locale :)
>
> TLDR; What you want to do is impossible with the current implementation.
> Correcting it is really a waste of time, as something which works correct
> would be shabby at best.
> Implementing use of CLDR data is the way to go if you want something that is
> both reliable and works.
>
> The only bits the Locale plugin is good at (should be used for), is getting
> the system defined country/language.
>
> Cheers,
> Henry
>
>
Oh wait, I forgot.
LocalePlugin caches the values for the current locale at startup, so it
wouldn't work changing it later anyways.

Sorry for the noise (except the TLDR part).

Cheers,
Henry


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Henrik Sperre Johansen
In reply to this post by Henrik Sperre Johansen
On 27.04.2011 20:37, Henrik Sperre Johansen wrote:
> Don't tell me you didn't have an idea this would happen :)
> Or was it Igor I talked to it about in Lille?
>
> --
> View this message in context: http://forum.world.st/new-Cog-VMs-uploaded-tp3476543p3479109.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
Mmmhmm, that came out abit more distasteful in text than when phrased
internally...
The correct phrasing would be:
"Sorry I haven't found time to finish the rewrite I talked about, during
which I discovered this (didn't compile to see if it would cause an
issue for Cog though), but probably neglected to tell you.
For the reasons LocalePlugin is inadequate for those primitives as
mentioned in other mail, I doubt I'll find motivation to finish it
rather than do other things later on either."

So, thanks for taking the effort of updating from trunk, sorry I
couldn't be of any help.

Cheers,
Henry

Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Sven Van Caekenberghe
In reply to this post by Henrik Sperre Johansen

On 27 Apr 2011, at 20:35, Henrik Sperre Johansen wrote:

> Implementing use of CLDR data is the way to go if you want something that is
> both reliable and works.

This was mentioned by others too ( http://cldr.unicode.org/ ).
That would indeed be a nice project, and no ugly plugins would be needed, pure Smalltalk only, that we all can understand and debug.

Sven


Reply | Threaded
Open this post in threaded view
|

LocalePlugin (was: new Cog VMs uploaded)

David T. Lewis
In reply to this post by Henrik Sperre Johansen
On Wed, Apr 27, 2011 at 08:43:06PM +0200, Henrik Sperre Johansen wrote:

> On 27.04.2011 20:35, Henrik Sperre Johansen wrote:
> >Also note, primShortDateFormat does nothing with the Locale you specify.
> >
> >All the primitives return values for the current process locale. (Set at
> >startup to system locale rather than C)
> >
> >You'd need to forcibly change the process locale with primSetLocale from
> >ImmX11Plugin (which isn't available in the image, thank God), and hope your
> >linux has that locale installed
> >(Ubuntu f.ex. only comes with a single one installed by default, and
> >switching to anything but that or C will fail)
> >
> >Can't use primGetLocale (not accessible from image either :D ) to check if
> >it's been successful though, as that resets the locale to system locale :)
> >
> >TLDR; What you want to do is impossible with the current implementation.
> >Correcting it is really a waste of time, as something which works correct
> >would be shabby at best.
> >Implementing use of CLDR data is the way to go if you want something that
> >is
> >both reliable and works.
> >
> >The only bits the Locale plugin is good at (should be used for), is getting
> >the system defined country/language.
> >
> >Cheers,
> >Henry
> >
> >
> Oh wait, I forgot.
> LocalePlugin caches the values for the current locale at startup, so it
> wouldn't work changing it later anyways.
>
> Sorry for the noise (except the TLDR part).

If anyone is interested in learning about the VM, writing your own
plugin or improving an existing plugin is a great way to get started.
The LocalePlugin does not get much attention, so if someone has an
interest in improving it, this might make a good small project.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Philippe Marschall-2-3
In reply to this post by Eliot Miranda-2
On 27.04.2011 19:24, Eliot Miranda wrote:
>  
>
>
>
> can you post a stack trace from gdb?  Also, what linux system and what
> image are you using?

r2382 fixed it

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Philippe Marschall-2-3
In reply to this post by Eliot Miranda-2
On 27.04.2011 19:23, Eliot Miranda wrote:
> Philippe,
>
>     can you please profile before and after?  This could very well be to
> do with the additional cost of shallowCopy for contexts, but it is
> inevitable that a correct implementation is going to be more expensive
> than the simple block-copy.  The new implementation can be optimized,
> but we need to profile first to be sure we're tilting at the relevant
> windmill.


What kind of profiling do you have in mind, MessageTally?

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Eliot Miranda-2


On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <[hidden email]> wrote:
On <a href="tel:27.04.2011%2019" value="+12704201119">27.04.2011 19:23, Eliot Miranda wrote:
> Philippe,
>
>     can you please profile before and after?  This could very well be to
> do with the additional cost of shallowCopy for contexts, but it is
> inevitable that a correct implementation is going to be more expensive
> than the simple block-copy.  The new implementation can be optimized,
> but we need to profile first to be sure we're tilting at the relevant
> windmill.


What kind of profiling do you have in mind, MessageTally?

Yes, that would be fine.  Thanks!

best,
Eliot 

Cheers
Philippe



Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs uploaded

Philippe Marschall-2-3
On 29.04.2011 19:03, Eliot Miranda wrote:

>
>
> On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 27.04.2011 19 <tel:27.04.2011%2019>:23, Eliot Miranda wrote:
>     > Philippe,
>     >
>     >     can you please profile before and after?  This could very well
>     be to
>     > do with the additional cost of shallowCopy for contexts, but it is
>     > inevitable that a correct implementation is going to be more expensive
>     > than the simple block-copy.  The new implementation can be optimized,
>     > but we need to profile first to be sure we're tilting at the relevant
>     > windmill.
>
>
>     What kind of profiling do you have in mind, MessageTally?
>
>
> Yes, that would be fine.  Thanks!
OK, there you go. As you'll see the runtime is about the same, that's
because we do more iterations in the same time. Also note the time we're
spending in WriteStream >> #nextPutAll: with interestingly has a
different growing behavior than WriteStream >> #nextPut: (only 25% vs
100%). I already raised the issue once but people argued that the
current code is prefect.

Cheers
Philippe

r2370-tally1.txt (8K) Download Attachment
r2370-tally2.txt (9K) Download Attachment
r2382-tally1.txt (8K) Download Attachment
r2382-tally2.txt (7K) Download Attachment
12