- Pharo-dev - lists.pharo.org

[Pharo-project] [Fixed]: Issue 2856: Use unique URL to core from [Dev image]->World Menu->System>Software update

by Sean P. DeNigris

http://code.google.com/p/pharo/issues/detail?id=2856 In a 1.2 dev image, when a user chooses System>Software update, they see a dialog explaining how to get an updatable (i.e. core trunk) image (issue ). This link should be the unique URL that was just set up - http://www.pharo-project.org/pharo-download/unstable-core. Fix in PharoInbox: SLICE-Issue-2856-DevSoftwareUpdateShowsUnqiueCoreURL-SeanDeNigris.1 Sean -- View this message in context: http://forum.world.st/Fixed-Issue-2856-Use-unique-URL-to-core-from-Dev-imag… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 24, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Eliot Miranda

2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 23 August 2010 23:26, stephane ducasse <stephane.ducasse(a)free.fr> >> wrote: >> > Hi guys >> > >> > I'm thinking aloud... >> > I was wondering if we could not take advantage of a new class: Selector. >> > MethodDict would only contain selectors and not symbols. >> > >> > I remember that I talked about that with hernan. >> > >> >> Hmm.. i don't see obvious advantages. Do you? >> Most symbols (90% of cases), used as selectors, so it is likely that >> such refactoring will be nothing more, >> but just renaming the class :) >> > Personally I find it slightly annoying. Symbols are only used as selectors by convention, and the VM has placed no restriction on what objects can be used as selectors so that, e.g. when aggressively shrinking one can replace Symbols with SmallIntegers. Introducing a Selector class would obscure this possibility even more. However I find use of the term "symbol" where "selector" is meant even more annoying. I *hate* methodSymbol in MethodReference. It should be selector. 2Â¢ Eliot > > Maybe because there are things implemented in Symbol or similar that are > responsabilities of a Selector? > > I have no idea. But I did a quick search and methods like flushCache, > numArgs:,value:, isKeyword, cull:, etc, seems more from Selector > > Cheers > > mariano > > >> > Stef >> > >> > >> > _______________________________________________ >> > Pharo-users mailing list >> > Pharo-users(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 24, 2010

Re: [Pharo-project] 'foo' asTime

by HernÃ¡n Morales Durand

2010/8/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > ok here is my take on it: > Â Â Â Â - I would like to have a mini kernel where date time is just good enough for what the system needs > Â Â Â Â - then people load the framework they want and yes I love aconcagua and chalten but there is also chronos > Â Â Â Â so you see I would prefer that people pick the one they like. > Now people can have a different opinion and I would like to hear them :) > I have a different opinion :) - Time is presupposed in every computer system I've seen, I would like to have or see a system without Time. Such is the influence of Kant today. - If one could remove the time and experiment teaching the system like an idealist would do, this could open doors to whole new things. - Bottom line, I would like to replace time instead of having just one mini kernel Does time exists if nothing is changed? ;) HernÃ¡n

Aug. 24, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by Niko Schwarz

Has this been resolved? I still get an error saying that PluggableButtonMorphPlus and OBPluggableButtonMorphPlus define homonymous instance variables. Niko On Wed, Aug 18, 2010 at 9:04 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 17, 2010, at 11:16 PM, Lukas Renggli wrote: > >> Or you would keep the empty but deprecated class >> PluggableButtonMorphPlus in the image and make everybody happy :-) >> > > Yes, let's do that... > > Â Â Â Â Marcus > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Aug. 24, 2010

Re: [Pharo-project] [update 1.2] #12106

by Alexandre Bergel

Ok, thanks Alexandre On 24 Aug 2010, at 11:50, Noury Bouraqadi wrote: > Ocean == Object-oriented, Cross-platform, and Effective Api for Networking. > Ok. That's a just a sentence to fit the acronym ;-) > > It is a re-implementation of a networking library that does not require a socket plugin for the VM. > We (Luc and I) do it based on Alien. > > Noury > On 24 aoÃ»t 2010, at 16:05, Alexandre Bergel wrote: > >>> Luc and i restarted working on Ocean last week after vacation. We moved to 1.1 and improved socket a bit. >>> I'll carry on with the socket chapter too :-) >> >> In one sentence, what is Ocean? >> >> Alexandre >> >> >>> >>>> >>>> Stef >>>> >>>>> ok. I should have read all my emails before answering :-) >>>>> >>>>> Noury >>>>> On 22 aoÃ»t 2010, at 21:53, StÃ©phane Ducasse wrote: >>>>> >>>>>> >>>>>> 12106 >>>>>> ----- >>>>>> >>>>>> - Issue 2843: ColoredCodeStream not used. Thanks Marcus Denker. >>>>>> >>>>>> - Issue 2769: Fixes for broken SocketStream behavior. Thanks Andreas Raab >>>>>> >>>>>> Fix the loop in network tests. >>>>>> >>>>>> Stef >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 24, 2010

Re: [Pharo-project] Why is readStream on SequenceableCollection and not on Collection?

by Nicolas Cellier

2010/8/24 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > This cropped up in Dolphin some years back. Â IIRC, OA's answer was that streams historically worked on only Array and maybe something else. Â Having said that, they relaxed a constraint because it was harmless and a good idea. > > I'm not sure about streaming over a set; lack of order means that it might be tricky to maintain a reasonable position?? > Exactly, the Stream would hardly be positionable, unless you use a sort of OrderedSet... A ReadWriteStream would be problematic for the same reasons. What would be the interest of such a Stream ? (I mean something more than what just you can do with #do:or #add:) Nicolas > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Tuesday, August 24, 2010 7:18 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Why is readStream on SequenceableCollection and Â Â not on Collection? > > did you try with nile? > because I forgot (of course doing too many things) but the difference between squeak and VW was that > we could not have a stream on something else than string and array. Now this may have Â changed in squeak with the work of levente > or nicolas. > Stef > > On Aug 24, 2010, at 1:11 PM, Bart Gauquie wrote: > >> Dear list, >> >> is there a specific reason readStream is defined on SequenceableCollection and not on Collection? >> >> I want to for instance stream over a Set (in a non determined order). >> >> I tried to do readStream on a Set, but got an error that copyFrom:to: was not defined on Set; so: >> >> ReadStream>>on: aCollection >> >> I think should read: >> >> ReadStream>>on: aSequenceableCollection >> >> >> Or should I always use: collect: select: detect: protocols? >> >> Any thoughts on this? >> >> Kind Regards >> >> Bart >> >> -- >> imagination is more important than knowledge - Albert Einstein >> Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein >> Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein >> The true sign of intelligence is not knowledge but imagination. - Albert Einstein >> However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill >> It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill >> _______________________________________________ >> 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 >

Aug. 24, 2010

Re: [Pharo-project] [update 1.2] #12106

by Noury Bouraqadi

Ocean == Object-oriented, Cross-platform, and Effective Api for Networking. Ok. That's a just a sentence to fit the acronym ;-) It is a re-implementation of a networking library that does not require a socket plugin for the VM. We (Luc and I) do it based on Alien. Noury On 24 aoÃ»t 2010, at 16:05, Alexandre Bergel wrote: >> Luc and i restarted working on Ocean last week after vacation. We moved to 1.1 and improved socket a bit. >> I'll carry on with the socket chapter too :-) > > In one sentence, what is Ocean? > > Alexandre > > >> >>> >>> Stef >>> >>>> ok. I should have read all my emails before answering :-) >>>> >>>> Noury >>>> On 22 aoÃ»t 2010, at 21:53, StÃ©phane Ducasse wrote: >>>> >>>>> >>>>> 12106 >>>>> ----- >>>>> >>>>> - Issue 2843: ColoredCodeStream not used. Thanks Marcus Denker. >>>>> >>>>> - Issue 2769: Fixes for broken SocketStream behavior. Thanks Andreas Raab >>>>> >>>>> Fix the loop in network tests. >>>>> >>>>> Stef >>>>> >>>>> _______________________________________________ >>>>> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 24, 2010

Re: [Pharo-project] PackageInfo >> printOn:

by Mariano Martinez Peck

Or maybe we can add PackageInfo >> name ^ self packageName On Tue, Aug 24, 2010 at 4:54 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi. The current implementation of PackageInfo >> printOn: is this: > > printOn: aStream > > super printOn: aStream. > aStream nextPutAll: '(',self packageName,')'. > > So...it prints something like this: 'aPackageInfo(Collections-Weak)' > > most of the times I prefer to print 'Collections-Weak' > > in my image I change it to > > printOn: aStream > > aStream nextPutAll: self packageName. > > Do you think this can be useful for the rest or I just keep it in my image? > > Cheers > > Mariano >

Aug. 24, 2010

Re: [Pharo-project] Float>>basicAt: primitive for Cog

by Henrik Johansen

Den 24.08.2010 13:36, skrev Guillermo Polito: > Hi! > > taking a look at issue 2579 > http://code.google.com/p/pharo/issues/detail?id=2579 I saw it's all > done but: > > "The float access methods are an alternative to what is described in > 2580 / 2581 , didn't see this when I posted. > They are slightly slower in a CogVM when primitive fails, since you > will have 2 primitive failures before handling, but do not need the > Parser change which allows primitive pragmas with non-literal error > parameter. > > Either way, if this approach is chosen, we might as well write: (same > for basicAt:put:) > Float >> basicAt: index > <primitive: 38> > ^super basicAt: index > as ec is always nil in this case." > > That should replace > > Float >> basicAt: index > "...." > <primitive: 38> > | ec | > ec == nil ifTrue: "primitive not implemented; floats are in > big-endian/PowerPC order." > [^super basicAt: index]. > index isInteger ifTrue: [self errorSubscriptBounds: index]. > index isNumber > ifTrue: [^self basicAt: index asInteger] > ifFalse: [self errorNonIntegerIndex] > > -------------------------------------------------------------------------- > > I ran all the FloatTests and I got: > > -Cog VM: all green before and after the change. > -non-Cog VM: 1 failure (on testNaNCompare) before and after the change > I don't get any failures on a Windows-nonCog 4.0.2 vm... On what platform, and which parts of NaNCompare is failing exactly? > I can't see tests for the primitive failure, maybe we should have... > ? If primitive 38 fails, you're either not on a Cog vm, or the error conditions are exactly the same as for Object basicAt:. > Anyway, I wonder if this change is ok for the non-cog vm also. Does > anyone know? > Yes, of course, otherwise it wouldn't be an alternative ;) Cheers, Henry

Aug. 24, 2010

[Pharo-project] PackageInfo >> printOn:

by Mariano Martinez Peck

Hi. The current implementation of PackageInfo >> printOn: is this: printOn: aStream super printOn: aStream. aStream nextPutAll: '(',self packageName,')'. So...it prints something like this: 'aPackageInfo(Collections-Weak)' most of the times I prefer to print 'Collections-Weak' in my image I change it to printOn: aStream aStream nextPutAll: self packageName. Do you think this can be useful for the rest or I just keep it in my image? Cheers Mariano

Aug. 24, 2010