- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fonts directory necessary in pharo-dev

by Michael Rueger

Lukas Renggli wrote: > I've made a similar experience. Pharo only seems to use the fonts if > they are in a sub-directory of the image. It would be cool, if the > fonts would also be detected when they are in a sub-directory of the > VM or installed in the system. Maybe we can fix that on Saturday? ;-) The Sophie FileLocations package has a call to find the platform specific font directory (or even directories?). Michael

July 2, 2009

Re: [Pharo-project] Fonts directory necessary in pharo-dev

by Lukas Renggli

I've made a similar experience. Pharo only seems to use the fonts if they are in a sub-directory of the image. It would be cool, if the fonts would also be detected when they are in a sub-directory of the VM or installed in the system. Maybe we can fix that on Saturday? ;-) Lukas 2009/7/2 Simon Denier <Simon.Denier(a)inria.fr>: > Hi > > I juste downloaded the latest pharo 10342 and I noticed that if I > remove the Fonts folder, it does not look for DejaVu fonts already > installed on my MacOs system. Instead I got crappy fonts. > > Is this a known bug? > > -- > Â Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

July 2, 2009

Re: [Pharo-project] FasterSets

by Andres Valloud

Also, what happens in these cases? | set | set := Set new. bag := Bag new. bad add: 4 withOccurrences: 1000000000 "or equivalent code". set addAll: bag I am guessing the set will fail to grow and addAll: will fail, even though it should work. Maybe it won't happen with bags, or perhaps the example needs some massaging. Is the failure to grow handled gracefully? Note that I have not looked at the code because I have not had much chance to do that yet. Andres Valloud wrote: > Hmmm, I don't know though, usually the usage pattern with hashed > collections has been to presize explicitly and then add to them... what > kind of use cases are you dealing with? > > Henrik Johansen wrote: > >> Having spent a fair deal of time (in VisualWorks) worrying about my >> intial Set sizes, writing functions to precompute sane sizes for >> arbitrary inputs and adding changeCapacityTo: calls before addAll: >> operations due to performance issues on a case-by-case basis (Squeak/ >> Pharo doesn't even HAVE a changeCapacityTo: ), I have to strongly >> disagree. >> >> I'd rather spend my time thinking about my problem domain, and know >> the Set implementation handles the nitty-gritty details in a >> sufficiently smart way. >> >> Whether that means growing once to accomedate the worst case, then >> shrinking afterwards, or doing a grow check every X added items, in >> the unlikely event that what you're adding is a 3 million element >> Array with 10 unique objects, I don't really care. >> >> Cheers, >> Henry >> >> On Jul 2, 2009, at 7:38 10AM, Andres Valloud wrote: >> >> >> >>> (Set new: desiredCapacity) addAll: "consecutive integers" >>> >>> may be a better compromise. >>> >>> Andres. >>> >>> >>> StÃ©phane Ducasse wrote: >>> >>> >>>> Thanks this is really good. >>>> We will probably integrate these changes really fast >>>> >>>> On Jul 1, 2009, at 1:03 PM, Henrik Johansen wrote: >>>> >>>> >>>> >>>> >>>>> I took some time to check this yesterday, my comments on the code >>>>> itself are basically the same as what Lucas posted in the issue >>>>> tracker. >>>>> Works as advertised, but should probably clean out the "gunk" >>>>> which is >>>>> unused after it's integrated. >>>>> >>>>> Some feedback on possible improvements: >>>>> - What it does, is basically speed up the adds to the new array in a >>>>> grow that might happen Why not take this all to the logical >>>>> conclusion, and instead optimize an addAll: method to be used in >>>>> grow, >>>>> that assumes elements are not in set (and themselves are not >>>>> duplicates)? F.ex. it could also add to tally just once, instead of >>>>> one increase per element as the noCompareAdd: does. (an add method >>>>> with no tally add, no = object check, and no growCheck). >>>>> >>>>> - The usual addAll: method can be sped up in a similar way, by >>>>> performing one grow operation before adding elements if necessary >>>>> (pessimistically assuming all elements are unique), then use an add >>>>> method which does not check for grow need at all. (an add method >>>>> with >>>>> tally add and = object check, but no growCheck) >>>>> If desirable, you could also shrink the capacity after adds are >>>>> done, to match the real amount of new elements. >>>>> >>>>> Adding (1 to: 1200000) to a new Set with such an addAll: method took >>>>> 1/2 to 1/3rd the time of the regular addAll: method, even with the >>>>> lower grow cost of FasterSets. (Lower gains if Set is presized, >>>>> and if >>>>> hash-calculation is bigger part of cost) >>>>> >>>>> Note: If you want to stay ANSI-compatible, one tricky point in >>>>> such an >>>>> optimization is adding all objects in collection up to a nil >>>>> element, >>>>> then raising an error. (ie: must produce equivalent results to add: >>>>> performed of each of collections elements in sequence ) >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> >>>>> On Jun 25, 2009, at 8:55 03PM, StÃ©phane Ducasse wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> I would really like to assess FasterSets for Pharo1.1 >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> From: Ralph Boland <rpboland(a)gmail.com> >>>>>>> Date: June 25, 2009 8:30:13 PM CEDT >>>>>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>>>> Subject: Re: about fasterTests >>>>>>> >>>>>>> 2009/6/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> we are interest to get better libraries in pharo. >>>>>>>> If you want to join and help making sure that your code in >>>>>>>> integrated in >>>>>>>> pharo1.1 >>>>>>>> please say it and may be join the pharo mailing-list. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Yes, I would like my code 'FasterSets' added to Pharo. >>>>>>> I joined the pharo mailing list. >>>>>>> Today I will mail you my MIT license release. >>>>>>> Probably will take a couple of weeks (From Calgary, Canada) to get >>>>>>> there. >>>>>>> Once I am added as a contributer I will release my code to Pharo >>>>>>> for >>>>>>> verification. >>>>>>> In the meantime if any Squeakers try out my code and report bugs I >>>>>>> will fix them >>>>>>> before releasing to Pharo. >>>>>>> >>>>>>> Some comments: >>>>>>> >>>>>>> 1) Since FasterSets modifies low level methods in class Set and >>>>>>> its >>>>>>> subclasses it >>>>>>> may be incompatible with packages that create subclasses of Set >>>>>>> and then >>>>>>> override low level methods. If someone could send me a list of >>>>>>> package add-ons >>>>>>> to Pharo that do this then I can download them and make any >>>>>>> modifications >>>>>>> necessary for them to run with FasterSets and make these changes >>>>>>> part of my >>>>>>> release. Note that it is no more difficult to subclass from Set >>>>>>> with FasterSets >>>>>>> than without; it is just different and only different if you do >>>>>>> low level things. >>>>>>> >>>>>>> 2) FasterSets uses a method 'noCompareOrGrowAdd:' which adds >>>>>>> an element to a set without doing compares or growing the set. >>>>>>> Needless to say it is a private method. >>>>>>> I also have a public method 'nastyAddNew:' which, like >>>>>>> 'noCompareOrGrowAdd:' adds an element to a set without checking >>>>>>> if the >>>>>>> element is already there but does do a grow if needed. >>>>>>> This is useful (i.e. faster) in situations where you KNOW the >>>>>>> object >>>>>>> you are adding to a set is not there already. >>>>>>> However if the object IS already there then you now have two >>>>>>> of them in your set; i.e. you now have a subtle bug. >>>>>>> I use 'nastyAddNew:' in my code but never made it a part of >>>>>>> FasterSets >>>>>>> because it is questionable whether or not such a method should be >>>>>>> available generally. However, if I can decide I like the >>>>>>> 'nastyAddNew:' >>>>>>> method and am willing to use it despite its risks so can others >>>>>>> so there >>>>>>> is an argument for it being added. >>>>>>> While my expectation is that you don't want 'nastyAddNew:' in >>>>>>> Pharo >>>>>>> I thought you should at least be aware of it. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ralph Boland >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> >> . >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > . > >

July 2, 2009

Re: [Pharo-project] FasterSets

by Andres Valloud

Hmmm, I don't know though, usually the usage pattern with hashed collections has been to presize explicitly and then add to them... what kind of use cases are you dealing with? Henrik Johansen wrote: > Having spent a fair deal of time (in VisualWorks) worrying about my > intial Set sizes, writing functions to precompute sane sizes for > arbitrary inputs and adding changeCapacityTo: calls before addAll: > operations due to performance issues on a case-by-case basis (Squeak/ > Pharo doesn't even HAVE a changeCapacityTo: ), I have to strongly > disagree. > > I'd rather spend my time thinking about my problem domain, and know > the Set implementation handles the nitty-gritty details in a > sufficiently smart way. > > Whether that means growing once to accomedate the worst case, then > shrinking afterwards, or doing a grow check every X added items, in > the unlikely event that what you're adding is a 3 million element > Array with 10 unique objects, I don't really care. > > Cheers, > Henry > > On Jul 2, 2009, at 7:38 10AM, Andres Valloud wrote: > > >> (Set new: desiredCapacity) addAll: "consecutive integers" >> >> may be a better compromise. >> >> Andres. >> >> >> StÃ©phane Ducasse wrote: >> >>> Thanks this is really good. >>> We will probably integrate these changes really fast >>> >>> On Jul 1, 2009, at 1:03 PM, Henrik Johansen wrote: >>> >>> >>> >>>> I took some time to check this yesterday, my comments on the code >>>> itself are basically the same as what Lucas posted in the issue >>>> tracker. >>>> Works as advertised, but should probably clean out the "gunk" >>>> which is >>>> unused after it's integrated. >>>> >>>> Some feedback on possible improvements: >>>> - What it does, is basically speed up the adds to the new array in a >>>> grow that might happen Why not take this all to the logical >>>> conclusion, and instead optimize an addAll: method to be used in >>>> grow, >>>> that assumes elements are not in set (and themselves are not >>>> duplicates)? F.ex. it could also add to tally just once, instead of >>>> one increase per element as the noCompareAdd: does. (an add method >>>> with no tally add, no = object check, and no growCheck). >>>> >>>> - The usual addAll: method can be sped up in a similar way, by >>>> performing one grow operation before adding elements if necessary >>>> (pessimistically assuming all elements are unique), then use an add >>>> method which does not check for grow need at all. (an add method >>>> with >>>> tally add and = object check, but no growCheck) >>>> If desirable, you could also shrink the capacity after adds are >>>> done, to match the real amount of new elements. >>>> >>>> Adding (1 to: 1200000) to a new Set with such an addAll: method took >>>> 1/2 to 1/3rd the time of the regular addAll: method, even with the >>>> lower grow cost of FasterSets. (Lower gains if Set is presized, >>>> and if >>>> hash-calculation is bigger part of cost) >>>> >>>> Note: If you want to stay ANSI-compatible, one tricky point in >>>> such an >>>> optimization is adding all objects in collection up to a nil >>>> element, >>>> then raising an error. (ie: must produce equivalent results to add: >>>> performed of each of collections elements in sequence ) >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>> On Jun 25, 2009, at 8:55 03PM, StÃ©phane Ducasse wrote: >>>> >>>> >>>> >>>>> I would really like to assess FasterSets for Pharo1.1 >>>>> >>>>> Begin forwarded message: >>>>> >>>>> >>>>> >>>>>> From: Ralph Boland <rpboland(a)gmail.com> >>>>>> Date: June 25, 2009 8:30:13 PM CEDT >>>>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>>> Subject: Re: about fasterTests >>>>>> >>>>>> 2009/6/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> >>>>>> >>>>>>> we are interest to get better libraries in pharo. >>>>>>> If you want to join and help making sure that your code in >>>>>>> integrated in >>>>>>> pharo1.1 >>>>>>> please say it and may be join the pharo mailing-list. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>> Yes, I would like my code 'FasterSets' added to Pharo. >>>>>> I joined the pharo mailing list. >>>>>> Today I will mail you my MIT license release. >>>>>> Probably will take a couple of weeks (From Calgary, Canada) to get >>>>>> there. >>>>>> Once I am added as a contributer I will release my code to Pharo >>>>>> for >>>>>> verification. >>>>>> In the meantime if any Squeakers try out my code and report bugs I >>>>>> will fix them >>>>>> before releasing to Pharo. >>>>>> >>>>>> Some comments: >>>>>> >>>>>> 1) Since FasterSets modifies low level methods in class Set and >>>>>> its >>>>>> subclasses it >>>>>> may be incompatible with packages that create subclasses of Set >>>>>> and then >>>>>> override low level methods. If someone could send me a list of >>>>>> package add-ons >>>>>> to Pharo that do this then I can download them and make any >>>>>> modifications >>>>>> necessary for them to run with FasterSets and make these changes >>>>>> part of my >>>>>> release. Note that it is no more difficult to subclass from Set >>>>>> with FasterSets >>>>>> than without; it is just different and only different if you do >>>>>> low level things. >>>>>> >>>>>> 2) FasterSets uses a method 'noCompareOrGrowAdd:' which adds >>>>>> an element to a set without doing compares or growing the set. >>>>>> Needless to say it is a private method. >>>>>> I also have a public method 'nastyAddNew:' which, like >>>>>> 'noCompareOrGrowAdd:' adds an element to a set without checking >>>>>> if the >>>>>> element is already there but does do a grow if needed. >>>>>> This is useful (i.e. faster) in situations where you KNOW the >>>>>> object >>>>>> you are adding to a set is not there already. >>>>>> However if the object IS already there then you now have two >>>>>> of them in your set; i.e. you now have a subtle bug. >>>>>> I use 'nastyAddNew:' in my code but never made it a part of >>>>>> FasterSets >>>>>> because it is questionable whether or not such a method should be >>>>>> available generally. However, if I can decide I like the >>>>>> 'nastyAddNew:' >>>>>> method and am willing to use it despite its risks so can others >>>>>> so there >>>>>> is an argument for it being added. >>>>>> While my expectation is that you don't want 'nastyAddNew:' in >>>>>> Pharo >>>>>> I thought you should at least be aware of it. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ralph Boland >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >> >> > > . > >

July 2, 2009

[Pharo-project] Fonts directory necessary in pharo-dev

by Simon Denier

Hi I juste downloaded the latest pharo 10342 and I noticed that if I remove the Fonts folder, it does not look for DejaVu fonts already installed on my MacOs system. Instead I got crappy fonts. Is this a known bug? -- Simon

July 2, 2009

Re: [Pharo-project] FasterSets

by Henrik Johansen

Having spent a fair deal of time (in VisualWorks) worrying about my intial Set sizes, writing functions to precompute sane sizes for arbitrary inputs and adding changeCapacityTo: calls before addAll: operations due to performance issues on a case-by-case basis (Squeak/ Pharo doesn't even HAVE a changeCapacityTo: ), I have to strongly disagree. I'd rather spend my time thinking about my problem domain, and know the Set implementation handles the nitty-gritty details in a sufficiently smart way. Whether that means growing once to accomedate the worst case, then shrinking afterwards, or doing a grow check every X added items, in the unlikely event that what you're adding is a 3 million element Array with 10 unique objects, I don't really care. Cheers, Henry On Jul 2, 2009, at 7:38 10AM, Andres Valloud wrote: > > (Set new: desiredCapacity) addAll: "consecutive integers" > > may be a better compromise. > > Andres. > > > StÃ©phane Ducasse wrote: >> Thanks this is really good. >> We will probably integrate these changes really fast >> >> On Jul 1, 2009, at 1:03 PM, Henrik Johansen wrote: >> >> >>> I took some time to check this yesterday, my comments on the code >>> itself are basically the same as what Lucas posted in the issue >>> tracker. >>> Works as advertised, but should probably clean out the "gunk" >>> which is >>> unused after it's integrated. >>> >>> Some feedback on possible improvements: >>> - What it does, is basically speed up the adds to the new array in a >>> grow that might happen Why not take this all to the logical >>> conclusion, and instead optimize an addAll: method to be used in >>> grow, >>> that assumes elements are not in set (and themselves are not >>> duplicates)? F.ex. it could also add to tally just once, instead of >>> one increase per element as the noCompareAdd: does. (an add method >>> with no tally add, no = object check, and no growCheck). >>> >>> - The usual addAll: method can be sped up in a similar way, by >>> performing one grow operation before adding elements if necessary >>> (pessimistically assuming all elements are unique), then use an add >>> method which does not check for grow need at all. (an add method >>> with >>> tally add and = object check, but no growCheck) >>> If desirable, you could also shrink the capacity after adds are >>> done, to match the real amount of new elements. >>> >>> Adding (1 to: 1200000) to a new Set with such an addAll: method took >>> 1/2 to 1/3rd the time of the regular addAll: method, even with the >>> lower grow cost of FasterSets. (Lower gains if Set is presized, >>> and if >>> hash-calculation is bigger part of cost) >>> >>> Note: If you want to stay ANSI-compatible, one tricky point in >>> such an >>> optimization is adding all objects in collection up to a nil >>> element, >>> then raising an error. (ie: must produce equivalent results to add: >>> performed of each of collections elements in sequence ) >>> >>> Cheers, >>> Henry >>> >>> >>> On Jun 25, 2009, at 8:55 03PM, StÃ©phane Ducasse wrote: >>> >>> >>>> I would really like to assess FasterSets for Pharo1.1 >>>> >>>> Begin forwarded message: >>>> >>>> >>>>> From: Ralph Boland <rpboland(a)gmail.com> >>>>> Date: June 25, 2009 8:30:13 PM CEDT >>>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>> Subject: Re: about fasterTests >>>>> >>>>> 2009/6/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> >>>>>> we are interest to get better libraries in pharo. >>>>>> If you want to join and help making sure that your code in >>>>>> integrated in >>>>>> pharo1.1 >>>>>> please say it and may be join the pharo mailing-list. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>> Yes, I would like my code 'FasterSets' added to Pharo. >>>>> I joined the pharo mailing list. >>>>> Today I will mail you my MIT license release. >>>>> Probably will take a couple of weeks (From Calgary, Canada) to get >>>>> there. >>>>> Once I am added as a contributer I will release my code to Pharo >>>>> for >>>>> verification. >>>>> In the meantime if any Squeakers try out my code and report bugs I >>>>> will fix them >>>>> before releasing to Pharo. >>>>> >>>>> Some comments: >>>>> >>>>> 1) Since FasterSets modifies low level methods in class Set and >>>>> its >>>>> subclasses it >>>>> may be incompatible with packages that create subclasses of Set >>>>> and then >>>>> override low level methods. If someone could send me a list of >>>>> package add-ons >>>>> to Pharo that do this then I can download them and make any >>>>> modifications >>>>> necessary for them to run with FasterSets and make these changes >>>>> part of my >>>>> release. Note that it is no more difficult to subclass from Set >>>>> with FasterSets >>>>> than without; it is just different and only different if you do >>>>> low level things. >>>>> >>>>> 2) FasterSets uses a method 'noCompareOrGrowAdd:' which adds >>>>> an element to a set without doing compares or growing the set. >>>>> Needless to say it is a private method. >>>>> I also have a public method 'nastyAddNew:' which, like >>>>> 'noCompareOrGrowAdd:' adds an element to a set without checking >>>>> if the >>>>> element is already there but does do a grow if needed. >>>>> This is useful (i.e. faster) in situations where you KNOW the >>>>> object >>>>> you are adding to a set is not there already. >>>>> However if the object IS already there then you now have two >>>>> of them in your set; i.e. you now have a subtle bug. >>>>> I use 'nastyAddNew:' in my code but never made it a part of >>>>> FasterSets >>>>> because it is questionable whether or not such a method should be >>>>> available generally. However, if I can decide I like the >>>>> 'nastyAddNew:' >>>>> method and am willing to use it despite its risks so can others >>>>> so there >>>>> is an argument for it being added. >>>>> While my expectation is that you don't want 'nastyAddNew:' in >>>>> Pharo >>>>> I thought you should at least be aware of it. >>>>> >>>>> Regards, >>>>> >>>>> Ralph Boland >>>>> >>>> _______________________________________________ >>>> 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 >

July 2, 2009

Re: [Pharo-project] [squeak-dev] Forks, forks, forks

by Igor Stasenko

2009/7/2 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Thu, Jul 2, 2009 at 12:06 AM, Ralph Johnson <johnson(a)cs.uiuc.edu> wrote: >> >> The tendency to fork is a product of all Smalltalks, not just Squeak. > > as others have observed in the current spate of discussion the need to fork > can be minimised or avoided altogether by providing a small kernel image > that can load packages, and getting into the habit of writing one's > application as a set of packages and regularly building them up into an > image (nightly, weekly) starting from the kernel. > This approach also allows the VM and image representation to evolve (and > even fork!) because the kernel is amenable to transformation. Â So one can > create different forms of the kernel image with exactly the same apparent > image contents, but with object representations adapted for specific uses, > such as an extremely compact representation for embedded applications and a > simple one for performance and normal development, and one can have purely > interpreted VMs for hostile or memory-limited machines (iPhone does not > allow one to enable execution permission on mmap'ed memory) and JITs > forÂ performance and normal development. > IMO it is also easierÂ building up a kernel than carving it out of a > monolithic imageÂ to architect the necessary modularity support to allow > packages to be loaded that make major transformations such as adding a GUI > and replacing a standard i/o stack dump with an interactive debugger. > I hope that if such a beast becomes available that the community will make > the effort to port to it, which involves packaging their code, and we can > branch to our heart's content because images will be constructed not > constricting. Yes, and all Squeak forks could use such kernel as a base, except those who making own changes to VM. This is another reason for having a package-based development model. I remember we have discussed this before, but this idea & especially benefits which it could bring to us, were leaked from my mind :) P.S. can't resist CC-ing this to Pharo list. :) >> >> There is a company in town that developed a commercial product on >> VisualWorks 2.0. Â They customized it heavily. Â It is a sound >> generater, in fact the world's fastest synthesizer in which you can >> specify each waveform. Â It is used by musicians and for sound effects >> in movies. Â All the programming is done by two people. Â It provide a >> very nice UI in which you drag and drop sound objects to create your >> piece. Â When you say "play", the sound objects are converted into code >> for an array of DSPs, which execute the code to play the sounds. Â The >> process is nearly instantaneous. >> >> This company made a fork over ten years ago, and last I heard, had not >> caught up. Â They would like to run their software on Unix. Â It only >> runs on PC and Macs, and I think they have hacked the VM themselves to >> run on newer OSs. Â The binary, that is. Â But it was just too much >> trouble to convert their image, and didn't seem like it provided >> enough benefits. >> >> There are still a lot of companies running VSE applications in spite >> of the fact that it hasn't been supported for a decade. >> >> One of the great things about Smalltalk is that it is so open. Â You >> can change everything about it; the way the compiler works, the UI, >> the programming environment tools, what it means to send a message to >> an object that is not understood. Â You can change arrays, strings, >> booleans. Â Of course, if you do this then you are not longer >> compatible. Â If you hack Behavior and ClassDescription then the odds >> are that your hacks will not be compatible with other people's hacks. >> Every time a new version of the platform comes out, you'll have to go >> back and make sure none of your hacks are broken. Â Often they will be. >> >> Sometimes it is worth the pain. Â But often people just fork. Â They >> will lose all the nifty new features that come out, but it just isn't >> worth the trouble to keep up. >> >> I think the reason there is so much forking with Smalltalk is that >> application programmers don't have to depend on vendors. Â They can >> craft the environment to suit their own needs, and don't need to >> depend on someone who doesn't really understand their needs. Â There >> are disadvantages to forking, but it is easy and there are enough >> advantages that people will continue to do it. >> >> So, we need to learn to live in a world of forks. Â Seaside shows how >> it can be done. Â Squeak and VisualWorks, after all, are different >> forks from the original Xerox Smalltalk-80. >> >> -Ralph Johnson >> > > > > > -- Best regards, Igor Stasenko AKA sig.

July 2, 2009

[Pharo-project] Squeak: A New Community Development Model

by Damien

Sent to you by Damien via Google Reader: A New Community Development Model via The Squeak Oversight Board Blog by andreasraab on 7/1/09 In the board meeting today we had a nice discussion about how to move forward with a new community development model for Squeak. Here is an overview of the model and what will happen next: The goals The goal of this process is to get rid of as many hurdles as possible in the contribution process. We are trying to enable the community at large to improve Squeak, the core of the system and its supporting libraries. To do this, we are adopting processes that have been shown to work in commercial settings: The use of Monticello as the primary source code management system, free access for the developers to the main repositories, an incremental update process for both developers and users of Squeak. Repositories We will be setting up the following Monticello repositories: * http://source.squeak.org/trunk This will be the main repository for ongoing development. New code will be committed here, the repository will be world-readable and writable for the core-dev group. * http://source.squeak.org/tests This is the main repository for unit tests. It will be world-readable AND world-writable. We encourage everyone to write more tests and commit them, improve the existing tests and bring in entirely new test suites. * http://source.squeak.org/inbox This repository is intended as dropbox. Itâs usage will depend on what we make it out to be. The idea is to have it world-readable and world-writable, too. Developer access The board will manage developer access to the repositories at source.squeak.org. In the next days weâll send out a few âyou are pre-approvedâ messages to people who have proven to be active developers in the past in order to invite them to become a core developer. If you canât wait and absolutely want to be in on the action you can register yourself at http://source.squeak.org/ and send message to the board asking for access but most of the regular contributors (you know who you are) will be invited anyway. Rules of Engagement If you have used Monticello in projects with more than two developers in the past you already know the drill. If not, here are some useful guidelines: * Merge often. In particular when you pick up work and right before you intend to commit. * Exercise caution. This is a running system and breaking it needlessly is generally frowned upon. * Restrain yourself. Getting developer access doesnât mean you are free to put in every pet extension you always wanted to have without discussion. * If in doubt, ask. This is the corollary to the restrain yourself rule. Youâre not under pressure to ship a product, so you have the time to send a note saying âhey, Iâm planning to fix this old issue and it may have some side effect here or there. Anyone having a problem with that?â >>> Iâll add a Squeak-dev exception here: Any response from any non-developer can be entirely ignored in this context. * You break it, you fix it. If you change something you are generally expected to take care of the consequences, though there are some exceptions. If in doubt, ask * Do good and talk about it. When youâre done with whatever it is youâve been working on let people know about it. It can be as short as a note to Squeak-dev saying âhey, some of you might care that Iâve fixed the long standing bug with xyz. Update and enjoyâ I think that roughly covers it. Basically you will be working with a dozen (hopefully more) other developers on Squeak and weâll all have to learn how to make this work successfully. Updating We are in the process of developing an update process that can work seamlessly with Monticello. An early experiment is described here. We are evaluating alternative approaches, in particular the use of Installer since there are some shortcomings when using Monticello Configurations. Existing Work It is important to note that we will be trying very hard not to lose any work that is being done for Squeak 3.11. We will start with the package set that was used in the 3.10 release, then we will issue package updates to cover the missing delta up until 3.10.2. Following which we will reissue any changes done for 3.11 into the repositories. Things you can do from here: - Subscribe to The Squeak Oversight Board Blog using Google Reader - Get started using Google Reader to easily keep up with all your favorite sites

July 2, 2009

Re: [Pharo-project] why FileDirectory sucks

by StÃ©phane Ducasse

Ok I also like some parts of the rio api. Arg too much to do. Stef On Jul 1, 2009, at 11:32 PM, Michael Rueger wrote: > Igor Stasenko wrote: > >> how then i could write a 'FileDirectory default' in terms of URIs? >> 'file://.' asURI ? > > No, you would still write FileDirectory default :-) > > But then you would do something like > > (FileDirectory default uri resolveRelativePath: 'myDir/images') > directory > > I know, doesn't look to elegant, but it's of context you rarely really > work with directories, but rather paths. > > Also take into account the FileLocations package which gives you calls > for userDataURI, tempURI etc, allowing to transparently integrate with > you platform specific paths. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 2, 2009

[Pharo-project] PhidgetLab and NXTalk going live

by StÃ©phane Ducasse

> Hi, > > perhaps this is interesting for some people. We hope so. :-) > > I am glad to announce the availability, as of today, of two > Squeak-based projects that both deal with letting Squeak interface > with the surrounding world. > > > 1. PhidgetLab > > Phidgets are sensors and actuators that can be connected to a PC via > USB. So far, support for them in Squeak was not freely available - > this changes now. :-) A group of students in our group - Lysann > Kessler, Stephanie Platz, Thomas Klingbeil, Philipp Tessenow, and > Frank Schlegel - have developed PhidgetLab in fulfilment of a > coursework assignment. It provides a "low-level" Phidgets API in > Squeak, but is also integrated with Etoys. > > Behold: http://www.hpi.uni-potsdam.de/swa/projects/phidgetlab/ > > 2. NXTalk > > Over the past few years, we've made the occasional announcement of > this: it's Smalltalk on Lego Mindstorms NXT. It's a real Smalltalk VM > running on the NXT, with an image being interpreted. Now it's finally > available, including the VM source code. NXTalk is the outcome of > Martin Beck's MSc research; Martin is a former student in our group. > > Behold: http://www.hpi.uni-potsdam.de/swa/projects/nxtalk/ > > > Both projects' source code is MIT licensed. They both are based on > (L)GPLed software, though: PhidgetLab uses the Phidgets API from the > vendor, which is under the LGPL, and NXTalk uses NXOS, which is under > the GPL. > > We would be grateful for any suggestions for improvement - for both > the projects and the respective web pages alike. Experience reports > are, of course, most welcome too. Unfortunately, we cannot make the > required hardware available as easily as the software. ;-) > > > Please let us know what you think! > > > Best, > > Michael > > -- > > Robert Hirschfeld > Hasso-Plattner-Institut > hirschfeld(a)hpi.uni-potsdam.de > www.hpi.uni-potsdam.de/swa > _______________________________________________ > Etoys mailing list > Etoys(a)lists.laptop.org > http://lists.laptop.org/listinfo/etoys >

July 2, 2009