October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] "A Mentoring Course on Smalltalk" Code License

by Julian Fitzell

I'm not a real license expert but I do play one on TV... The license should be visible, easy to find, and clearly associated with the code in question. Also, as Monty pointed out at ESUG, make sure it is possible for people to comply with the terms of your license. MIT license specifically requires the user to maintain the copyright notice, so make sure you *have* a copyright notice! I have no idea if this is relevant in this case--it's just a general observation but I mention it here because it's one of my big concerns with open source at the moment--but make sure the contributors (and not their employers) all own the intellectual property. In many (even most) jurisdictions, full-time employees may find that their employer by default owns much of the code they write, even what is written in their spare time. Contractors usually own their code by default but most companies who are on the ball will try to assign the ownership to them in the contract. Whether you're a full-time employee or a contractor, check your contracts before contributing to open-source. It is much easier to request a written IP exclusion in advance than to try to transfer ownership later. You're doing everyone a disservice if you pollute open source projects with code that has questionable IP ownership; the difficulty of defining derivative works makes it very hard to predict the difficulty of fixing the problem. Julian On Fri, Oct 1, 2010 at 3:23 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > Andres Valloud-4 wrote: >> >> Well, since this discussion is public now :) >> > hee hee > > > Andres Valloud-4 wrote: >> >> ... exactly what seems to be >> the problem? Â The book talks about code that is often in the public >> Store repository. Â Is the problem that the code in the public Store >> repository doesn't have an MIT license? Â Or is the problem that the book >> that talks about the code in the public Store repository doesn't say >> "and the code has an MIT license"? >> > > Would a license expert weigh in here? Â Andres, would it be difficult to add > a note to the book specifying that the code in it is MIT? > -- > View this message in context: http://forum.world.st/A-Mentoring-Course-on-Smalltalk-Code-License-tp271425… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Mariano Martinez Peck

Thanks to everybody. I did what you say and now MessageTally time: [ECContextTest new testUntypedVarsOnly] -> 3023 I've just commited OCompletion. And I didn't know TimeProfiler :) cheers Mariano On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: > > On 28.09.2010 01:43, Levente Uzonyi wrote: >> >>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: >>> >>> On 28.09.2010 00:41, Levente Uzonyi wrote: >>>> >>>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: >>>>> >>>>> On 28.09.2010 00:07, Levente Uzonyi wrote: >>>>>> >>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>>>> >>>>>>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu> >>>>>>>> >>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>>>>>> >>>>>>>>> IF you take a 1.1 core and just load OCompletion: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 >>>>>>>>>> >>>>>>>>>> If you load OCompletion and the rest of the dev image: >>>>>>>>>> >>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> However, IN pharo dev 1.0 it is >>>>>>>>>> >>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> sooo.... ???? >>>>>>>>>> >>>>>>>>>> something has changed? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> As I said, SortedCollection is not suitable for this kind of usage. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> But in Pharo 1.0 OCompletion was doing the same....so? did >>>>>>>> SortedCollection >>>>>>>> chang between 1.0 and 1.1? >>>>>>>> >>>>>>> >>>>>>> No, something else changed. The same test is still 5x faster in 1.0 >>>>>>> dev with the new code. >>>>>>> >>>>>> TimeProfiler to the rescue: >>>>>> Preferences class >> ecompletionCaseSensitive >>>>>> 1.0: (1725ms) >>>>>> 1.1 (19724ms) >>>>>> >>>>>> Preference>>settingValue which is there for backwards-compatability in >>>>>> 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower >>>>>> than the old dictionary lookup. >>>>>> >>>>> >>>>> Nice find. If you check my code, you'll find that I optimized that >>>>> away. :) >>>>> >>>>> >>>>> Levente >>>>> >>>> Yes ,you moved it out of the actual sort loop :) >>>> Rewrite the methods in ECPreferences to use the new syntax: >>>> <preference: category: description: type:>, and you shouldn't even have >>>> to do that to get ok performance. >>>> >>>> IMHO, it's rather disturbing to see things like EC, where its >>>> preferences are actually separated tucked away in an ECPreferences class, >>>> only to be delegated from there over to Preferences... >>>> >>> >>> The preferences should be updated, but sending a message once is still >>> better than 2k-30k times. >>> >>> >>> Levente >>> >> Sure, on the order of a couple of milliseconds difference. >> I keep forgetting the fact we generally have different definitions of what >> constitutes "ok performance" ;) >> > > 30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick > image has 3220 globals. The sortBlock asks for the preference twice per > evaluation. SortedCollection uses a binary search during #add:. If we are > optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 times > which is ~75k. > > In the same image the "old" code asked for the preference 2282899 times > during the tests, while the new code did it only 398 times. If the > preference is changed to return the value of a variable, then the difference > is only 80 ms, otherwise it's 36.6 seconds. > > > Levente > > > >> Cheers, >> Henry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2010

Re: [Pharo-project] NativeBoost and Cog. A working protype.

by Igor Stasenko

On 1 October 2010 10:33, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > Just a thought, > > I would say that Lukas Helvetia framework could be used here, Â to cleanly embed C++, C or whatever you like Â syntax into the existing Smalltalk ambient. > Yes, I like the idea of using Helvetia. I would be cool to invent some kind of platform-neutral assembler language. If one likes to write C or C++ , it would be cool too. > So in the background NativeBoost would behave more uniformly, because everything in the end is smalltalk code. > > Fernando > > > On Oct 1, 2010, at 8:39 AM, Schwab,Wilhelm K wrote: > >> Sig, >> >> I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't. >> >> One performance penalty that I look forward to suffering is to have an external library calling into Pharo to do function evaluations. Â In most cases, the number of operations will be small and the convenience of having the code in the image will be most welcome. >> >> Bill >> >>>> ...... > > > >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen(a)pairhome.net] >>>> Sent: Thursday, September 30, 2010 11:33 AM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype. >>>> >>>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>> On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>>> One really crazy idea: inline C. Â Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Â Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was >>>>> >>>>> void LogOnePlus(double * data, unsigned long size) >>>>> /* >>>>> Â Â Â Add one and take log10() over the buffer; in-place transformation! >>>>> */ >>>>> { >>>>> Â Â Â for(unsigned long i=0; i<size; i++){ >>>>> Â Â Â data[i] = log10(data[i]+1); >>>>> Â Â Â } >>>>> } >>>>> >>>>> That's a simple calculation, but do it millions of times and it adds up. Â Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Â Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :) >>>>> >>>> >>>> Of course its possible. >>>> After porting C parser/compiler into smalltalk :) >>>> Or perhaps some meta-language which looks like C, but which easier to >>>> translate to native code. >>>> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2010

[Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1

by Sven Van Caekenberghe

Mariano, On 01 Oct 2010, at 09:55, Mariano Martinez Peck wrote: > Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ > > This CogVM version fixes the problem with "Objects as methods", and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM. > > The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Super! Thanks a lot for all the effort (and the persistence). Although I am already on 1.1.1 and Cog myself, this version is a very important milestone for end users. I will certainly check it out. Sven

Oct. 1, 2010

[Pharo-project] [update 1.2] #12160

by Marcus Denker

12160 ----- Issue 3022: Custom help books should be able to define where subbooks should be placed/displayed Issue 2980: dropping a text file into the host window raises an error -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 1, 2010

[Pharo-project] [Progress Report] Zinc HTTP Components

by Sven Van Caekenberghe

Here is a quick progress report regarding the Zinc HTTP Components project. Please check the SqueakSource history for a all the details. The external documentation has not yet been updated ;-) I am very pleased that Matt Kennedy joined the project as a developer and is contributing lots of really important and interesting code - way to go Matt! Some highights are: - we now have cookie handling, authentication and credential objects - there is a new ZnUserAgent client that can do advanced authentication handles cookies, sessions and that can follow redirects - there is a ZnFixedClient that can reuse a connection to the same host/port - there is support for client side chunked and gzip decoding - there is an experimental server that keeps connections alive (unfinised) - support classes ZnUserAgentSession and ZnUserAgentSession - lots of refactorings, fixes and portability improvements - the number of unit tests has increased to 71 Sven

Oct. 1, 2010

[Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1

by Mariano Martinez Peck

Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ This CogVM version fixes the problem with "Objects as methods", and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM. The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip Cheers Mariano

Oct. 1, 2010

Re: [Pharo-project] Alien Plugin for Linux

by Fernando olivero

Thanks for the information Noury! Now we can safely assume the the official Alien package is in the Alien repository. I will look into the answer from Henrik, and try to have a cleaner Alien-Core package, with less overrides. Fernando On Sep 29, 2010, at 8:11 PM, Noury Bouraqadi wrote: > HI Fernando, > > It was a bug fix. And we hadn't at that time access to the Alien repo for saving it. > Currently, we have a metacello config and it refers the alien repo. > > Noury > On 29 sept. 2010, at 15:20, Fernando olivero wrote: > >> A question to the Ocean developers, why do have a particular Alien-Core package in the ocean repo? ( Alien-Core-LucFabresse.64.mcz ) >> >> Are there some fixes that could be included in the official package? Please let me know so i can integrate them. >> >> I'm asking because i'm cleaning a bit the Alien mess, ( see previous mail) , and would like to have a single working official Alien. >> >> Thanks, >> Fernando >> >> On Sep 29, 2010, at 12:56 PM, Fernando olivero wrote: >> >>> This Error prevents from using Alien in the lastest Pharo image. >>> >>> I will try to fix this today. >>> >>> Also i will remove the ConfigurationOfAlien from the Alien repository, because the version in MetacelloRepository should be used instead. >>> So there are no future misunderstandings >>> >>> >>> Thanks to Eliot, and using his precompiled Vms for all platforms Alien would be available now! >>> (if the mentioned bug were fixed). >>> >>> >>> Fernando >>> >>> >>> On Sep 28, 2010, at 12:05 PM, Igor Stasenko wrote: >>> >>>> On 28 September 2010 11:51, Henrik Johansen >>>> <henrik.s.johansen(a)veloxit.no> wrote: >>>>> On Sep 28, 2010, at 10:34 16AM, Alberto Bacchelli wrote: >>>>> >>>>>> On 9/27/10 8:13 PM, Eliot Miranda wrote: >>>>>>> >>>>>>> >>>>>>> 2010/9/27 Fernando olivero<fernando.olivero(a)usi.ch<mailto:fernando.olivero@usi.ch>> >>>>>>> Does the prebuilt CogVM for linux include Alien support? >>>>>>> http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ >>>>>>> >>>>>>> Only of the data manipulation and callout parts, not the callback parts. I'm trying to find time to work on integrating the Alien callback machinery with the FFI. >>>>>>> >>>>>>> best >>>>>>> Eliot >>>>>> >>>>>> We had a problem after installing Alien, >>>>>> when running the tests. >>>>>> >>>>>> The following does not understand >>>>>> >>>>>> MessageNotUnderstood: Array>>createMethod:header:methodClass: >>>>>> >>>>>> sent by >>>>>> CompileMethod class>>newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive: >>>>>> >>>>>> It appears to be cog related, is it? >>>>>> >>>>>> Thank you, >>>>>> Alberto >>>>> >>>>> No, it's Method-trailer related. >>>>> >>>>> IIRC, the convention used to be to pass the empty trailer bytes #(0 0 0 0), find the offending sender and change it to pass CompiledMethodTrailer empty instead. >>>>> >>>> >>>> Right. A more compatible way is to use SomeClass defaultMethodTrailer >>>> Where SomeClass should be a class, where you installing this method. >>>> >>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 1, 2010

Re: [Pharo-project] NativeBoost and Cog. A working protype.

by Fernando olivero

Just a thought, I would say that Lukas Helvetia framework could be used here, to cleanly embed C++, C or whatever you like syntax into the existing Smalltalk ambient. So in the background NativeBoost would behave more uniformly, because everything in the end is smalltalk code. Fernando On Oct 1, 2010, at 8:39 AM, Schwab,Wilhelm K wrote: > Sig, > > I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't. > > One performance penalty that I look forward to suffering is to have an external library calling into Pharo to do function evaluations. In most cases, the number of operations will be small and the convenience of having the code in the image will be most welcome. > > Bill > >>> ...... >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen(a)pairhome.net] >>> Sent: Thursday, September 30, 2010 11:33 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype. >>> >>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>> On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>> One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was >>>> >>>> void LogOnePlus(double * data, unsigned long size) >>>> /* >>>> Add one and take log10() over the buffer; in-place transformation! >>>> */ >>>> { >>>> for(unsigned long i=0; i<size; i++){ >>>> data[i] = log10(data[i]+1); >>>> } >>>> } >>>> >>>> That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :) >>>> >>> >>> Of course its possible. >>> After porting C parser/compiler into smalltalk :) >>> Or perhaps some meta-language which looks like C, but which easier to >>> translate to native code. >>>

Oct. 1, 2010

Re: [Pharo-project] NativeBoost and Cog. A working protype.

by Denis Kudriashov

Hello 2010/10/1 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > I'm pointing out that "do it all in Smalltalk" has limits, both in syntax > (C++ is generally a better formula translator than Smalltalk; Smalltalk is > better at expressing just about anything else) I have many complex math stuff implemented in smalltalk and C in university. And my experience that no matter C or smalltalk you use for formula (equation) programming. In any case it will be not math formula like on paper. And readability will be bad. Debugging is bad because of complex calculations and diffirences in math formula and program language analogue. Just see fast fourier transformation. Equations is not so complex. But programme implementation... Ideally programming math formula or equation should not exists for user. You just put native math formula presentation to system and get results. Maybe similar solution exists?

Oct. 1, 2010