- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Athens + Amber + HTML5 canvas

by Damien Cassou

On Wed, Nov 28, 2012 at 11:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Any takers? :) what do you think of this proposal: http://rmod.lille.inria.fr/web/pier/research/ProjectsProposal/Amber-html5-c… -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Dec. 17, 2012

Re: [Pharo-project] CI down?

by Max Leske

I know, but I couldn't remember the address :p On 17.12.2012, at 00:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I repeat: Do not use the CI to download stuff from... > > Use our static file server: http://pharo.gforge.inria.fr/ci/ > > > ci jobs may change names and jenkins is too brittle to support heavy traffic! > > > On 2012-12-16, at 13:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Dec 16, 2012, at 5:24 PM, Max Leske wrote: >> >>> ah, thanks. >>> >>> I wanted to update the links on the pharo-project page but there's stuff missing (or I don't know where it is), e.g. the one-click build and the vm zips (from the dedicated download server). >> >> We should change everything. Now we are waiting that the inria service really open (currently in beta) and at the same time we saturated our disc space so we had to kill >> the old integration server. >> >> Stef > >

Dec. 17, 2012

Re: [Pharo-project] Interval protocol

by Frank Shearar

On 17 December 2012 07:28, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 16 December 2012 16:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Beware, Range exists in other languages (python, etc..). >>> We should check if they correspond to a Smalltalk Interval or a >>> mathematical Interval. >>> If they correspond to a Smalltalk Interval, that will be one more >>> un-necessary trap. >>> >>> Note that we rarely use Interval, we just use #to: or #to:by:, so we >>> could as well rename Interval->Range. >>> And postpone creation of Mathematical Interval which is most likely >>> unused in kernel image. >> >> >> Why not? Now it would be good to move. >> but what I know is that igor wanted to have range intersection for the new text model. >> Another question: who thinks that ruby look at Smalltalk when they take a decision on their library? >> I do not think so. We can check what is around and **improve** our nice system > > If you use Ruby for any length of time (and ignore most of the syntax) > you will quickly realise that Ruby _is_ Smalltalk in many fundamental > ways. It's just a pity Matz based its syntax on Perl (or so it seems). > Ruby = Smalltalk with rubbish syntax and awesome integration with > basic programmer tools and decent infrastructure. I should add: with that last clause I'm not trying to dismiss Pharo's and Squeak's massive improvement in infrastructure. It's just that it's nowhere near as slick as in Ruby. frank > frank > >> Stef >> >>> 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I agree so we should introduce Range. >>>> Did not you or camillo started to have Range? >>>> It can be a really nice class. >>>> >>>> Stef >>>> On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote: >>>> >>>>> So, to my sense a behavior of Interval is overloaded.. >>>>> it tries to be too many things at once: >>>>> - be an interval in math sense (which is infinite set if used for Real numbers) >>>>> - be a "collection" of numbers which you can enumerate (implies that >>>>> it is finite). >>>>> >>>>> to me, i would be much happier if we could have two different and >>>>> non-intersecting entities: >>>>> >>>>> - Enumeration. This one indeed can be used as a collection. i.e. >>>>> "give me all integer numbers lying between values A and B, count each >>>>> C-th number" >>>>> Like that, >>>>> (1 to: 1.5 by: 1) is enumeration which contains a single element. >>>>> and #last should be = 1 >>>>> >>>>> - Interval (Range). A pure interval in math sense: defines a Set of >>>>> numbers lying between numbers A and B, inclusive, where A <= B. Not >>>>> enumerable, therefore no 'step' variable, instead what it could have, >>>>> is flags to indicate whether interval endpoints included into interval >>>>> or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. >>>>> >>>>> Not supporting enumeration (no #do: , no #add: no #at: etc). You can, >>>>> however intersect, merge or diff two intervals etc.. same operations >>>>> which you doing on sets (but that would require another entity - >>>>> interval set). And of course, you can test whether some number lies >>>>> within given interval or not. >>>>> >>>>> The reason i started this topic is because some code were using >>>>> 'range' for variables which holding intervals.. >>>>> Now what you think is more appropriate protocol for something called >>>>> 'range', this: >>>>> >>>>> x := range first >>>>> y := range last >>>>> >>>>> or this: >>>>> >>>>> x := range start >>>>> y := range end >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >> >>

Dec. 17, 2012

Re: [Pharo-project] Interval protocol

by Frank Shearar

On 16 December 2012 16:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Beware, Range exists in other languages (python, etc..). >> We should check if they correspond to a Smalltalk Interval or a >> mathematical Interval. >> If they correspond to a Smalltalk Interval, that will be one more >> un-necessary trap. >> >> Note that we rarely use Interval, we just use #to: or #to:by:, so we >> could as well rename Interval->Range. >> And postpone creation of Mathematical Interval which is most likely >> unused in kernel image. > > > Why not? Now it would be good to move. > but what I know is that igor wanted to have range intersection for the new text model. > Another question: who thinks that ruby look at Smalltalk when they take a decision on their library? > I do not think so. We can check what is around and **improve** our nice system If you use Ruby for any length of time (and ignore most of the syntax) you will quickly realise that Ruby _is_ Smalltalk in many fundamental ways. It's just a pity Matz based its syntax on Perl (or so it seems). Ruby = Smalltalk with rubbish syntax and awesome integration with basic programmer tools and decent infrastructure. frank > Stef > >> 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> I agree so we should introduce Range. >>> Did not you or camillo started to have Range? >>> It can be a really nice class. >>> >>> Stef >>> On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote: >>> >>>> So, to my sense a behavior of Interval is overloaded.. >>>> it tries to be too many things at once: >>>> - be an interval in math sense (which is infinite set if used for Real numbers) >>>> - be a "collection" of numbers which you can enumerate (implies that >>>> it is finite). >>>> >>>> to me, i would be much happier if we could have two different and >>>> non-intersecting entities: >>>> >>>> - Enumeration. This one indeed can be used as a collection. i.e. >>>> "give me all integer numbers lying between values A and B, count each >>>> C-th number" >>>> Like that, >>>> (1 to: 1.5 by: 1) is enumeration which contains a single element. >>>> and #last should be = 1 >>>> >>>> - Interval (Range). A pure interval in math sense: defines a Set of >>>> numbers lying between numbers A and B, inclusive, where A <= B. Not >>>> enumerable, therefore no 'step' variable, instead what it could have, >>>> is flags to indicate whether interval endpoints included into interval >>>> or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. >>>> >>>> Not supporting enumeration (no #do: , no #add: no #at: etc). You can, >>>> however intersect, merge or diff two intervals etc.. same operations >>>> which you doing on sets (but that would require another entity - >>>> interval set). And of course, you can test whether some number lies >>>> within given interval or not. >>>> >>>> The reason i started this topic is because some code were using >>>> 'range' for variables which holding intervals.. >>>> Now what you think is more appropriate protocol for something called >>>> 'range', this: >>>> >>>> x := range first >>>> y := range last >>>> >>>> or this: >>>> >>>> x := range start >>>> y := range end >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> > >

Dec. 17, 2012

Re: [Pharo-project] CI down?

by Jimmie Houchin

On 12/16/2012 5:45 PM, Camillo Bruni wrote: > I repeat: Do not use the CI to download stuff from... > > Use our static file server: http://pharo.gforge.inria.fr/ci/ > > ci jobs may change names and jenkins is too brittle to support heavy traffic! I think the easiest way to encourage this would be to change the website to point to the latest stable version of each of the images and vms. And reduce the links to the ci server to the server itself and never to any jobs or artifacts on it. Let the only links to jobs or artifacts on the ci server come from the ci server and not the Pharo website. Its a shame that there is not a CI app in Pharo as opposed to Java/Jenkins. Maybe someday. Jimmie

Dec. 17, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Camillo Bruni

so for all those who still want "FileDirectory" semantics available, you can load the FileSystem-Compatibility package from here: http://smalltalkhub.com/#!/~dh83/fisleg/packages/FileSystem-Legacy I think we should provide a configuration and add it to the MetacelloRepository. And btw, there is your backward-compatiblity. Except for some weird Mac-specific file-type stuff that is currently missing from FileSystem everything works without changing a single line of code. so that invalidates the whole thread IMO.

Dec. 17, 2012

Re: [Pharo-project] CI down?

by Camillo Bruni

I repeat: Do not use the CI to download stuff from... Use our static file server: http://pharo.gforge.inria.fr/ci/ ci jobs may change names and jenkins is too brittle to support heavy traffic! On 2012-12-16, at 13:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 16, 2012, at 5:24 PM, Max Leske wrote: > >> ah, thanks. >> >> I wanted to update the links on the pharo-project page but there's stuff missing (or I don't know where it is), e.g. the one-click build and the vm zips (from the dedicated download server). > > We should change everything. Now we are waiting that the inria service really open (currently in beta) and at the same time we saturated our disc space so we had to kill > the old integration server. > > Stef

Dec. 16, 2012

Re: [Pharo-project] Anonymous subclasses support

by Igor Stasenko

On 16 December 2012 22:38, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > > > On Sun, Dec 16, 2012 at 9:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 16 December 2012 19:42, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> wrote: >> > Hi guys, >> > >> > Can somebody tell what is the correct way of creating anonymous classes >> > in >> > Pharo? >> > When I say correct way I mean something that does not break the image or >> > the >> > tools. >> > >> > The thing is that we can use them in NativeBoost and I cannot stop >> > running >> > into errors because of these anonymous classes. >> > Is it just me or maybe we should do something about it... >> > >> > I am really frustrated about this thing because everybody knows that we >> > can >> > do it... but at the end of the day it is not working properly, >> > and has bizzare side effects. >> > >> >> Depends what you wanna do. >> >> > What about an official API for doing this? Or at least a way to check if >> > your class is anonymous so that we can refactor the tools to ignore them >> > or >> > something... >> > >> Using anonymous classes with tools which written to work with public ones >> will never work. >> There are too many places on different levels of system with strong >> assumptions about how things are organized. >> Perhaps if you tell, what you trying to do, we can see how to deal >> with problems. >> > > > I'm writing a FFI generator for Pharo that uses libclang to parse header > files and generates nativeboost mapping as output. > The beast is almost working (I can get libclang mapping, the core.h > header)but there are still some small issues. So, that's why I've been > poking at nativeboost ;) > > At the end I expect to have something that will generate correct ffi > interface, and that will not bloat the image with thousand of visible > classes, so that the user might get a chance to understand something of what > I'm generating... > indirection is your savior :) You can implement similar functionality as in ExternalArray, but instead of generating a pair of methods per class, make a class which holds following information: data type getter setter where getter and setter is generated functions for converting external value back and forth.. then in at: at:put: primitives should call these functions. With this setup you will need only single class, which instances responsible for holding rest of information about type & handling conversion of values. I know , this will make code a bit more complicated, but at the end you will not need to deal with anonymous classes anymore. Also, since you need only single getter/setter per value type, you can share them via cache controlled by class side. So, instead of climbing the wall, you can walk around it ;) > The thing is this evening after 4-5 hours of looking around my conclusion > is. In pharo 1.4 the anonymous subclasses are breaking the tools, and in the > brand new pharo 2.0 the refactoring tools (RBNamespace & company) are not > working as they should.... so i'm stuck with 1.4 for now (and still telling > to myself that I do not want to bloat the image with many classes) > > Well that's about it for now... > -- Best regards, Igor Stasenko.

Dec. 16, 2012

Re: [Pharo-project] Anonymous subclasses support

by Ciprian Teodorov

On Sun, Dec 16, 2012 at 11:41 PM, Ciprian Teodorov < ciprian.teodorov(a)gmail.com> wrote: > > > On Sun, Dec 16, 2012 at 11:02 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> > I'm writing a FFI generator for Pharo that uses libclang to parse >> header files and generates nativeboost mapping as output. >> > The beast is almost working (I can get libclang mapping, the core.h >> header)but there are still some small issues. So, that's why I've been >> poking at nativeboost ;) >> > >> > At the end I expect to have something that will generate correct ffi >> interface, and that will not bloat the image with thousand of visible >> classes, so that the user might get a chance to understand something of >> what I'm generating... >> > >> > The thing is this evening after 4-5 hours of looking around my >> conclusion is. In pharo 1.4 the anonymous subclasses are breaking the >> tools, and in the brand new pharo 2.0 the refactoring tools (RBNamespace & >> company) are not working as they should.... so i'm stuck with 1.4 for now >> (and still telling to myself that I do not want to bloat the image with >> many classes) >> >> Can you tell us what is the problem you got with RBNamespace? >> Because if we know we can try to fix it :). >> > > When executing the refactorings that generate my code I get a DNU... (see > attached .png) it seem that RBAddMethodChange does not implement the > #includesSelector: > > actually no the #classChange selector gives me a nil ? I don't know... > >> Stef >> >> >> > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 16, 2012

Re: [Pharo-project] Anonymous subclasses support

by Ciprian Teodorov

On Sun, Dec 16, 2012 at 11:02 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > I'm writing a FFI generator for Pharo that uses libclang to parse header > files and generates nativeboost mapping as output. > > The beast is almost working (I can get libclang mapping, the core.h > header)but there are still some small issues. So, that's why I've been > poking at nativeboost ;) > > > > At the end I expect to have something that will generate correct ffi > interface, and that will not bloat the image with thousand of visible > classes, so that the user might get a chance to understand something of > what I'm generating... > > > > The thing is this evening after 4-5 hours of looking around my > conclusion is. In pharo 1.4 the anonymous subclasses are breaking the > tools, and in the brand new pharo 2.0 the refactoring tools (RBNamespace & > company) are not working as they should.... so i'm stuck with 1.4 for now > (and still telling to myself that I do not want to bloat the image with > many classes) > > Can you tell us what is the problem you got with RBNamespace? > Because if we know we can try to fix it :). > When executing the refactorings that generate my code I get a DNU... (see attached .png) it seem that RBAddMethodChange does not implement the #includesSelector: > > Stef > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 16, 2012