[Pharo-project] new Cog VMs uploaded
...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
2011/4/26 Eliot Miranda <eliot.miranda@gmail.com>:
...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 =================================================
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
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 <eliot.miranda@gmail.com>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
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 <eliot.miranda@gmail.com>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 <eliot.miranda@gmail.com>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
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
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 <kustos@gmx.net> wrote:
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
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 -- View this message in context: http://forum.world.st/new-Cog-VMs-uploaded-tp3476543p3479100.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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
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
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
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 URL: http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/unix/plugins/Local... 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 <kustos@gmx.net> wrote:
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
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.
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
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
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 <kustos@gmx.net> wrote:
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
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
On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <kustos@gmx.net> wrote:
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?
Yes, that would be fine. Thanks! best, Eliot
Cheers Philippe
On 29.04.2011 19:03, Eliot Miranda wrote:
On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net>> 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
On Sun, May 1, 2011 at 4:38 AM, Philippe Marschall <kustos@gmx.net> wrote:
On 29.04.2011 19:03, Eliot Miranda wrote:
On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net>> 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.
Hmmm. GC behaviour is very different. Also requestContext Also shows up in the 2382 profiles but not the 2370 traces. You'll need to dig a little deeper to account for these differences. I guess they could well be to do with the new (correct) MethodContext copying behaviour retaining more state and hence stressing the GC more.
Cheers Philippe
On 03.05.2011 19:51, Eliot Miranda wrote:
On Sun, May 1, 2011 at 4:38 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net>> wrote:
On 29.04.2011 19:03, Eliot Miranda wrote: > > > On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net> > <mailto:kustos@gmx.net <mailto:kustos@gmx.net>>> wrote: > > On 27.04.2011 19 <tel:27.04.2011%2019> <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.
Hmmm. GC behaviour is very different. Also requestContext Also shows up in the 2382 profiles but not the 2370 traces. You'll need to dig a little deeper to account for these differences. I guess they could well be to do with the new (correct) MethodContext copying behaviour retaining more state and hence stressing the GC more.
What approach do you suggest should I take? Cheers Philippe
On Tue, May 3, 2011 at 11:57 AM, Philippe Marschall <kustos@gmx.net> wrote:
On 03.05.2011 19:51, Eliot Miranda wrote:
On Sun, May 1, 2011 at 4:38 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net>> wrote:
On 29.04.2011 19:03, Eliot Miranda wrote: > > > On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net> > <mailto:kustos@gmx.net <mailto:kustos@gmx.net>>> wrote: > > On 27.04.2011 19 <tel:27.04.2011%2019> <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.
Hmmm. GC behaviour is very different. Also requestContext Also shows up in the 2382 profiles but not the 2370 traces. You'll need to dig a little deeper to account for these differences. I guess they could well be to do with the new (correct) MethodContext copying behaviour retaining more state and hence stressing the GC more.
What approach do you suggest should I take?
I have no idea. You could try and break down the various activities and benchmark them separately I suppose. You could look at the profiles you're already generating in higher resolution to see where the time is going. You could also try and extract the SystemProfiler from OpenQwaq, which will run on Cog, and is better than MessageTally. Andreas wrote it to get around some of MessageTally's limitations. It should hopefully show primitives quite accurately. HTH Eliot
Cheers Philippe
On 5/3/2011 4:40 PM, Eliot Miranda wrote:
What approach do you suggest should I take?
I have no idea. You could try and break down the various activities and benchmark them separately I suppose. You could look at the profiles you're already generating in higher resolution to see where the time is going. You could also try and extract the SystemProfiler from OpenQwaq, which will run on Cog, and is better than MessageTally. Andreas wrote it to get around some of MessageTally's limitations. It should hopefully show primitives quite accurately.
Here is where the OpenQwaq GPL licensing gets tricky. I am not bashing the GPL decision, I have already written in defense of it. But it does make extracting code like this a little more challenging. Does the author and/or Teleplace wish to provide an MIT license on the extracted code? Otherwise it is hard or impossible (???) to use in Pharo or Squeak. I am hopeful that Teleplace will on an issue by issue basis allow such extraction and re-licensing with appropriate credits. It would definitely should good faith and citizenship in the broader Smalltalk community. Jimmie
You should be able to extract the code and use it in Pharo/Squeak without issue, even if it is GPL. What you can't do is include it in the distribution, since it isn't MIT. You also shouldn't study the code and write your own version of it - I believe that would be a derivative work, which would likely make it a GPL derivative. However, if it was extracted, and you brought it in to do profiling, and then removed it afterwards, that shouldn't be an issue at all. Just remember to remove it after you no longer need it - that way the GPL code won't accidentally creep into the Pharo/Squeak code-base. Basically, this would be a great example of a project that should be an external project and not part of core (or dev). -Chris
Hi chris
You should be able to extract the code and use it in Pharo/Squeak without issue, even if it is GPL. What you can't do is include it in the distribution, since it isn't MIT. You also shouldn't study the code and write your own version of it - I believe that would be a derivative work, which would likely make it a GPL derivative.
so it does not exist and this is better because GPL is viral and we do not want it.
However, if it was extracted, and you brought it in to do profiling, and then removed it afterwards, that shouldn't be an issue at all. Just remember to remove it after you no longer need it - that way the GPL code won't accidentally creep into the Pharo/Squeak code-base.
Basically, this would be a great example of a project that should be an external project and not part of core (or dev).
the problem is that this kind of philosophy goes against the spirit of smalltalk of been able to read and learn the code and modify it.
-Chris
On 4 May 2011 23:39, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi chris
You should be able to extract the code and use it in Pharo/Squeak without issue, even if it is GPL. Â What you can't do is include it in the distribution, since it isn't MIT. Â You also shouldn't study the code and write your own version of it - I believe that would be a derivative work, which would likely make it a GPL derivative.
so it does not exist and this is better because GPL is viral and we do not want it.
I finding it really funny that GPL were invented to help open-source to rise and spread, and now its just stands in your way, as any other closed-source proprietary one...
However, if it was extracted, and you brought it in to do profiling, and then removed it afterwards, that shouldn't be an issue at all. Just remember to remove it after you no longer need it - that way the GPL code won't accidentally creep into the Pharo/Squeak code-base.
Basically, this would be a great example of a project that should be an external project and not part of core (or dev).
the problem is that this kind of philosophy goes against the spirit of smalltalk of been able to read and learn the code and modify it.
I think that Teleplace has not much choice under which license to release this code, because as long as you using even portion of GPL-ed code, you are forced to use GPL as well.
-Chris
-- Best regards, Igor Stasenko AKA sig.
You should be able to extract the code and use it in Pharo/Squeak without issue, even if it is GPL. What you can't do is include it in the distribution, since it isn't MIT. You also shouldn't study the code and write your own version of it - I believe that would be a derivative work, which would likely make it a GPL derivative.
so it does not exist and this is better because GPL is viral and we do not want it.
I finding it really funny that GPL were invented to help open-source to rise and spread, and now its just stands in your way, as any other closed-source proprietary one...
GPL is more than free software it is a nearly a societal model that I respect.
However, if it was extracted, and you brought it in to do profiling, and then removed it afterwards, that shouldn't be an issue at all. Just remember to remove it after you no longer need it - that way the GPL code won't accidentally creep into the Pharo/Squeak code-base.
Basically, this would be a great example of a project that should be an external project and not part of core (or dev).
the problem is that this kind of philosophy goes against the spirit of smalltalk of been able to read and learn the code and modify it.
I think that Teleplace has not much choice under which license to release this code, because as long as you using even portion of GPL-ed code, you are forced to use GPL as well.
And also it avoids that you can do business with it without contributing back which I understand well too. I do not criticize teleplace decision. I just warn us against using any code from there.
On Wed, May 4, 2011 at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 May 2011 23:39, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi chris
You should be able to extract the code and use it in Pharo/Squeak without issue, even if it is GPL. What you can't do is include it in the distribution, since it isn't MIT. You also shouldn't study the code and write your own version of it - I believe that would be a derivative work, which would likely make it a GPL derivative.
so it does not exist and this is better because GPL is viral and we do not want it.
I finding it really funny that GPL were invented to help open-source to rise and spread, and now its just stands in your way, as any other closed-source proprietary one...
However, if it was extracted, and you brought it in to do profiling, and then removed it afterwards, that shouldn't be an issue at all. Just remember to remove it after you no longer need it - that way the GPL code won't accidentally creep into the Pharo/Squeak code-base.
Basically, this would be a great example of a project that should be an external project and not part of core (or dev).
the problem is that this kind of philosophy goes against the spirit of smalltalk of been able to read and learn the code and modify it.
I think that Teleplace has not much choice under which license to release this code, because as long as you using even portion of GPL-ed code, you are forced to use GPL as well.
You have it backwards. There is *no* GPL code in OpenQwaq. If there had been the whole project would have had to become GPL and Teleplace could not have protected itself against others using the code. By releasing the code as GPL Teleplace's investors retain the sole commercial rights to the code. No-one else can use the code without their contributions becoming GPL. Hence no-one wanting to do commercial development using OpenQwaq can do so and protect their contributions. Teleplace's investors, however, /can/ subsequently sell or exploit commercial rights to the code, which they still hold.
-Chris
-- Best regards, Igor Stasenko AKA sig.
You have it backwards. There is *no* GPL code in OpenQwaq. If there had been the whole project would have had to become GPL and Teleplace could not have protected itself against others using the code. By releasing the code as GPL Teleplace's investors retain the sole commercial rights to the code. No-one else can use the code without their contributions becoming GPL. Hence no-one wanting to do commercial development using OpenQwaq can do so and protect their contributions. Teleplace's investors, however, /can/ subsequently sell or exploit commercial rights to the code, which they still hold. A policy that even Richard Stallman sees as good use of GPL...
On 5 May 2011 18:24, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, May 4, 2011 at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 May 2011 23:39, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi chris
You should be able to extract the code and use it in Pharo/Squeak without issue, even if it is GPL. Â What you can't do is include it in the distribution, since it isn't MIT. Â You also shouldn't study the code and write your own version of it - I believe that would be a derivative work, which would likely make it a GPL derivative.
so it does not exist and this is better because GPL is viral and we do not want it.
I finding it really funny that GPL were invented to help open-source to rise and spread, and now its just stands in your way, as any other closed-source proprietary one...
However, if it was extracted, and you brought it in to do profiling, and then removed it afterwards, that shouldn't be an issue at all. Just remember to remove it after you no longer need it - that way the GPL code won't accidentally creep into the Pharo/Squeak code-base.
Basically, this would be a great example of a project that should be an external project and not part of core (or dev).
the problem is that this kind of philosophy goes against the spirit of smalltalk of been able to read and learn the code and modify it.
I think that Teleplace has not much choice under which license to release this code, because as long as you using even portion of GPL-ed code, you are forced to use GPL as well.
You have it backwards. Â There is *no* GPL code in OpenQwaq. Â If there had been the whole project would have had to become GPL and Teleplace could not have protected itself against others using the code. Â By releasing the code as GPL Teleplace's investors retain the sole commercial rights to the code. Â No-one else can use the code without their contributions becoming GPL. Â Hence no-one wanting to do commercial development using OpenQwaq can do so and protect their contributions. Â Teleplace's investors, however, /can/ subsequently sell or exploit commercial rights to the code, which they still hold.
Ah, yes.. sorry. i'm not expert in this legal stuff anyways :) Thanks for explanation. -- Best regards, Igor Stasenko AKA sig.
this is why you often see dual licensing GPL/buying a license. So it makes sense. Licences are tools to shape your business model Now for pharo this is MIT because if you want you can run out with it and sell it for a lot of money :) Stef
You have it backwards. There is *no* GPL code in OpenQwaq. If there had been the whole project would have had to become GPL and Teleplace could not have protected itself against others using the code. By releasing the code as GPL Teleplace's investors retain the sole commercial rights to the code. No-one else can use the code without their contributions becoming GPL. Hence no-one wanting to do commercial development using OpenQwaq can do so and protect their contributions. Teleplace's investors, however, /can/ subsequently sell or exploit commercial rights to the code, which they still hold.
Ah, yes.. sorry. i'm not expert in this legal stuff anyways :) Thanks for explanation.
-- Best regards, Igor Stasenko AKA sig.
On 03.05.2011 23:40, Eliot Miranda wrote:
On Tue, May 3, 2011 at 11:57 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net>> wrote:
On 03.05.2011 19:51, Eliot Miranda wrote: > > > On Sun, May 1, 2011 at 4:38 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net> > <mailto:kustos@gmx.net <mailto:kustos@gmx.net>>> wrote: > > On 29.04.2011 19:03, Eliot Miranda wrote: > > > > > > On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall > <kustos@gmx.net <mailto:kustos@gmx.net> > <mailto:kustos@gmx.net <mailto:kustos@gmx.net>> > > <mailto:kustos@gmx.net <mailto:kustos@gmx.net> > <mailto:kustos@gmx.net <mailto:kustos@gmx.net>>>> wrote: > > > > On 27.04.2011 19 <tel:27.04.2011%2019> <tel:27.04.2011%2019> > <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. > > > Hmmm. GC behaviour is very different. Also requestContext Also shows > up in the 2382 profiles but not the 2370 traces. You'll need to dig a > little deeper to account for these differences. I guess they could well > be to do with the new (correct) MethodContext copying behaviour > retaining more state and hence stressing the GC more.
What approach do you suggest should I take?
I have no idea.
You understand that when I hear these words from a VM guru I get a bit worried about the challenges ahead of me.
You could try and break down the various activities and benchmark them separately I suppose. You could look at the profiles you're already generating in higher resolution to see where the time is going. You could also try and extract the SystemProfiler from OpenQwaq, which will run on Cog, and is better than MessageTally. Andreas wrote it to get around some of MessageTally's limitations. It should hopefully show primitives quite accurately.
I'll see what I can do. Cheers Philippe
On 03.05.2011 23:40, Eliot Miranda wrote:
On Tue, May 3, 2011 at 11:57 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net>> wrote:
On 03.05.2011 19:51, Eliot Miranda wrote: > > > On Sun, May 1, 2011 at 4:38 AM, Philippe Marschall <kustos@gmx.net <mailto:kustos@gmx.net> > <mailto:kustos@gmx.net <mailto:kustos@gmx.net>>> wrote: > > On 29.04.2011 19:03, Eliot Miranda wrote: > > > > > > On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall > <kustos@gmx.net <mailto:kustos@gmx.net> > <mailto:kustos@gmx.net <mailto:kustos@gmx.net>> > > <mailto:kustos@gmx.net <mailto:kustos@gmx.net> > <mailto:kustos@gmx.net <mailto:kustos@gmx.net>>>> wrote: > > > > On 27.04.2011 19 <tel:27.04.2011%2019> <tel:27.04.2011%2019> > <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. > > > Hmmm. GC behaviour is very different. Also requestContext Also shows > up in the 2382 profiles but not the 2370 traces. You'll need to dig a > little deeper to account for these differences. I guess they could well > be to do with the new (correct) MethodContext copying behaviour > retaining more state and hence stressing the GC more.
What approach do you suggest should I take?
I have no idea. You could try and break down the various activities and benchmark them separately I suppose. You could look at the profiles you're already generating in higher resolution to see where the time is going. You could also try and extract the SystemProfiler from OpenQwaq, which will run on Cog, and is better than MessageTally. Andreas wrote it to get around some of MessageTally's limitations. It should hopefully show primitives quite accurately.
Ok, here we go. Cheers Philippe
participants (12)
-
Chris Cunningham -
David T. Lewis -
Eliot Miranda -
Germán Arduino -
Henrik Sperre Johansen -
Igor Stasenko -
Jimmie Houchin -
Philippe Marschall -
Scott Gibson -
Stéphane Ducasse -
Sven Van Caekenberghe -
Toon Verwaest