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

Re: [Pharo-project] how to get nice native fonts in 1.0

by Henrik Johansen

On Jan 20, 2010, at 8:48 10AM, StÃ©phane Ducasse wrote: > Hi > > I have to give some demos of seaside today and I would like to have nice fonts in 1.0 > and I cannot find the preferences to say that the fonts can be looked up on my disc. > > > Stef I don't think there is one... If Native fonts don't show up in the selection list, or they do, but are preview-rendered as Accuny, pressing the Update button should do the trick. Cheers, Henry

Jan. 20, 2010

Re: [Pharo-project] After OB, compare to current version uses old diff

by Mariano Martinez Peck

I created the issue http://code.google.com/p/pharo/issues/detail?id=1855 On Tue, Jan 19, 2010 at 8:38 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Gary: I compared that method before and after loading OB and it is the > same. > > The method is from gvc 2/9/2009 12:45 like this: > > > compareToOtherVersion > "Prompt the user for a reference version, then spawn a window > showing the diffs between the older and the newer of the current > version and the reference version as text." > > | change1 change2 s1 s2 | > change1 := changeList at: listIndex ifAbsent: [^self]. > change2 := UIManager default > chooseFrom: (list copyWithoutIndex: listIndex) > values: (changeList copyWithoutIndex: listIndex). > change2 ifNil: [^self]. > s1 := change1 string. > s2 := change2 string. > s1 = s2 ifTrue: [^self inform: 'Exact Match' translated]. > (DiffMorph > from: s1 > to: s2 > contextClass: change1 methodClass) > openInWindowLabeled: (('Comparison from {1} to {2}' translated) > format: {change1 stamp. change2 stamp}) > > > > > > On Tue, Jan 19, 2010 at 8:29 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> do you have the correct version? >> The problem is certainly link with override and moving package around >> (this is bogus with MC). >> >> Stef >> >> >> On Jan 19, 2010, at 7:00 PM, Gary Chambers wrote: >> >> > Clearly the cruicial method is overwritten... >> VersionsBrowser>>compareToOtherVersion. >> > >> > Regards, Gary >> > ----- Original Message ----- >> > From: Mariano Martinez Peck >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Sent: Tuesday, January 19, 2010 5:57 PM >> > Subject: Re: [Pharo-project] After OB,compare to current version uses >> old diff >> > >> > >> > >> > 2010/1/19 Gary Chambers <gazzaguru2(a)btinternet.com> >> > Unless code has changed then the setting for "Use Polymorph difference >> tools" should do. >> > I expect some code regression may have happened though. >> > >> > Thanks Gary. The preference is the one Henrik said, >> useNewDiffToolsForMC, but it is not working for me. You can try it like >> this: take the latest PharoCore 1.0 image, (10506). You will notice that it >> is working with the new diff. Then, evaluate: >> > >> > Gofer new >> > squeaksource: 'MetacelloRepository'; >> > package: 'ConfigurationOfOmniBrowser'; >> > load. >> > >> > >> > ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: '1.0') >> load. >> > >> > Or download OB by hand from Lukas repo. >> > >> > After this, you will notice it uses the old diff even if the preference >> is enable and even disabling it and enabling again. >> > >> > Cheers >> > >> > Mariano >> > >> > >> > Regards, Gary >> > ----- Original Message ----- >> > From: Mariano Martinez Peck >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Sent: Tuesday, January 19, 2010 4:35 PM >> > Subject: Re: [Pharo-project] After OB,compare to current version uses >> old diff >> > >> > >> > >> > On Tue, Jan 19, 2010 at 5:22 PM, Henrik Johansen < >> henrik.s.johansen(a)veloxit.no> wrote: >> > Preferences >> useNewDiffToolsForMC? >> > >> > I tried this before sending the email, but not. I didn't work :( >> > >> > >> > There was some discussion some time back, I believe Lukas stated he >> liked the old tools better. >> > >> > Ok..didn't know. >> > >> > Can't say I blame him, I'm never quite sure if I'm installing new one or >> keeping old when merging from MC until after the fact when I use the >> Polymorph tools ... >> > >> > >> > I can blame him at all. He is helping us a lot maintaining OB a lot. If >> we use his OB repository, then we should adapt to him. I don't pretend he >> change his default values or preferences. I just want to know how to set up >> again the new diff :) >> > >> > Cheers >> > >> > Mariano >> > >> > Cheers, >> > Henry >> > >> > On Jan 19, 2010, at 5:05 26PM, Mariano Martinez Peck wrote: >> > >> > > Hi: If you take a PharoCore image, and browse the editions of a class, >> then select an older one, and then select "compare to current", you see the >> differences using the "new" diff, the same that we use in MC. >> > > >> > > However, after installing OB in a core image, it uses the "old" >> version. I am not sure that change is due to OB, but at least it seems. I >> checked in Preferences but I didn't find anything. >> > > >> > > Any hint how to put new diff again after installing OB ? >> > > >> > > Thanks! >> > > >> > > Mariano >> > > _______________________________________________ >> > > 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 >> > _______________________________________________ >> > 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 >> > >

Jan. 20, 2010

Re: [Pharo-project] We remove CodeLoader ?? [WAS] Presenter and Project will die aren't they ?

by Mariano Martinez Peck

On Wed, Jan 20, 2010 at 9:13 AM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > if you follow the send into CodeLoader you will see fileIn sent at the > end of installSourceFile:. All the security manager stuff and request > stuff can be dropped so just try and copy the minimum that you need > into the class. Yes, I thought the same. > Also, the startup at login can be dropped as well, > since the class can be activated or deactivated by removing it from > the startup list. ahh cool :) > I'll take a look later on. > > Excellent. I created http://code.google.com/p/pharo/issues/detail?id=1854 I wanted to put you in cc but I didn't find you in the list :( Thanks Mariano > cheers, > Mike > > 2010/1/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Tue, Jan 19, 2010 at 6:12 PM, Michael Roberts <mike(a)mjr104.co.uk> > wrote: > >> > >> we can remove it but we need to keep the ability to load scripts from > >> the command line. > >> > > > > Mike: Thanks for you answer. I really don't know too much of CodeLoader, > > that's why I ask. I checked that about running from command line. You are > > right. > > > > > >> > >> so, your code is fine but you can't zap CodeLoader since it's still > >> referenced for the load. It would be easier just to make a new class > >> that only loads scripts from the command line, and zap the rest. > >> > > > > Yes, maybe that's a better idea. However, I think that maybe we even > don't > > need a new class. Maybe we can do something like this: > > > > startUpAfterLogin > > | scriptName loader isUrl | > > self readDocumentAtStartup ifTrue: [ > > scriptName := (SmalltalkImage current getSystemAttribute: 2) > > ifNil:['']. > > scriptName := scriptName convertFromSystemString.. > > ] > > ifFalse: [ scriptName := '' ]. > > > > scriptName isEmptyOrNil > > ifTrue:[^ self]. > > > > self loadAndInstallSources: scriptName. > > > > > > And then, we define ProjectLauncher >> loadAndInstallSources: aScriptName > > > > Here we should do a fileIn, but I am not sure how to do that. Can you > help > > me ? > > > > What do you think ? Is it worth this or keep CodeLoader ? I reall don't > > LIKE AT ALL to use something that depends on HTTPLoader to do that...wtf > > ??? Look CodeLoader >> createRequestFor: > > > > Please, take into account I am very newbie with this stuff, so maybe > there > > are a lot of problems I am not seeing. I just asked :) > > > > Cheers > > > > Mariano > > > > > >> cheers > >> Mike > >> > >> 2010/1/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> > So....we will remove CodeLoader then ? This is the moment to speak > :) > >> > > >> > I ask about this because I am trying to analize who uses ImageSegments > >> > and > >> > all that stuff in the code and see how easily or good is to remove > >> > ImageSegment to a separate package. And, CodeLoader uses ImageSegment. > >> > > >> > As far as I looked, the only user or CodeLoader, as Michael said is > >> > ProjectLauncher >> startUpAfterLogin > >> > Which....I think it will also die in a moment if Project will die > >> > too.... > >> > > >> > Anyway, but do you think about changing startUpAfterLogin to this: > >> > > >> > startUpAfterLogin > >> > | scriptName loader isUrl | > >> > self readDocumentAtStartup ifTrue: [ > >> > scriptName := (SmalltalkImage current getSystemAttribute: 2) > >> > ifNil:['']. > >> > scriptName := scriptName convertFromSystemString. > >> > scriptName isEmpty ifFalse:[ > >> > "figure out if script name is a URL by itself" > >> > isUrl := (scriptName asLowercase beginsWith:'http://') > or:[ > >> > (scriptName asLowercase beginsWith:'file://') or:[ > >> > (scriptName asLowercase beginsWith:'ftp://')]]. > >> > isUrl ifFalse:[scriptName := 'file:',scriptName]]. > >> > . ] > >> > ifFalse: [ scriptName := '' ]. > >> > > >> > scriptName isEmptyOrNil > >> > ifTrue:[^ self]. > >> > loader := CodeLoader new. > >> > loader loadSourceFiles: (Array with: scriptName). > >> > loader installSourceFiles. > >> > > >> > > >> > > >> > On Tue, Jan 12, 2010 at 9:56 AM, StÃ©phane Ducasse > >> > <stephane.ducasse(a)inria.fr> wrote: > >> >> > >> >> ok we got convinced :) > >> >> > >> >> On Jan 12, 2010, at 8:20 AM, John M McIntosh wrote: > >> >> > >> >> > Ah well yes Michael suffered thru managing, testing, and working > with > >> >> > all those browsers & plugins. > >> >> > I suffered thru trying to figure out how it all worked... At least > >> >> > on > >> >> > the mac. > >> >> > > >> >> > Here's the current issue, because: > >> >> > > >> >> > Microsoft shafted netscape by abandoning the netscape API, then > >> >> > shafted > >> >> > apple by not providing an alternative > >> >> > we had the strange mixture of a solution for os-x, windows, X11. > >> >> > Then > >> >> > of course Microsoft IE on macintosh > >> >> > would change behaviour from version to version to screw with > FireFox > >> >> > & > >> >> > Mozilla etc. Let alone worrying about Opera which > >> >> > kinda worked. Fortunately Microsoft abandon the Mac browser > market, > >> >> > and Apple introduced Safari which again was slightly different. > >> >> > > >> >> > Now on 10.6 we had this problem an abandon API for plugins, that > >> >> > needed > >> >> > to move forward, also into the 64bit world. > >> >> > So Apple changed things again to either let you run Safari in 32bit > >> >> > using old plugins (busted), or using a modified 64bit plugins api, > >> >> > but > >> >> > not both at the same time. > >> >> > > >> >> > The words busted, non-existant, abandon, (implied ugly), appear > >> >> > quite a > >> >> > few times in the sentences above. Also on every > >> >> > browser version change, or operating system major version change > >> >> > something was just slightly funky enough to bring down > >> >> > the house of cards. > >> >> > > >> >> > So, time is better spent in getting 64bit squeak working, since > there > >> >> > is > >> >> > plenty of hours still needed to fixup all the plugins, > >> >> > and check that the VM is actually sane... > >> >> > > >> >> > > >> >> > On 2010-01-11, at 1:59 PM, Michael Rueger wrote: > >> >> > > >> >> >> On 1/11/2010 10:58 PM, Michael Rueger wrote: > >> >> >> > >> >> >>> forget squeak/pharo in the browser. > >> >> >> > >> >> >> for those not in the know: > >> >> >> I'm one of the poor guys who actually spent a *lot* of time making > >> >> >> it > >> >> >> possible ;-) > >> >> >> > >> >> >> Michael > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Pharo-project mailing list > >> >> >> Pharo-project(a)lists.gforge.inria.fr > >> >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> >> > > >> >> > -- > >> >> > > >> >> > > >> >> > > =========================================================================== > >> >> > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > >> >> > squeaker68882 > >> >> > Corporate Smalltalk Consulting Ltd. > >> >> > http://www.smalltalkconsulting.com > >> >> > > >> >> > > >> >> > > =========================================================================== > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > 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 > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010

Re: [Pharo-project] Question on recursive structures

by Levente Uzonyi

On Wed, 20 Jan 2010, Viktor Kerkez wrote: > Hi, > > Since this is my first post on the list, first I want to thank you all for > the great job you're doing on Pharo :) It was a real revelation when I > discovered it :) > > Now to the question: > > I'm reading the Pharo by Example, and came to this part: > > The problem with deepCopy is that it will not terminate when applied to a > mutually recursive structure: > a1 := { 'harry' }. > a2 := { a1 }. > a1 at: 1 put: a2. > a1 deepCopy ËË! ... does not terminate! Use #veryDeepCopy. #deepCopy doesn't support object graphs with circles. Note that you can't use objects with recursive graphs in an environment which sends #hash to the objects (like sets, dictionaries, or a workspaces), because collections' hash calculation doesn't work if the object graph is recursive. Example: This works in a workspace: | a b c | a := { 1 }. b := { a }. a at: 1 put: b. c := a veryDeepCopy. But this doesn't: a := { 1 }. b := { a }. a at: 1 put: b. c := a veryDeepCopy. There are other things you can't do with such objects, like printing. > > (Pharo actually get stuck at the step: a1 at: 1 put: a2. but that's not the > question :) ) > > 1. Isn't this behaviour (the complete environment get stuck and there is no > way to unfreeze it) considered a bug? I mean the environment shouldn't let > you shoot yourself in the foot (at least not so easily). Actually the same > behaviour can be created just doing: [true] whileTrue: []... > > 2. Shouldn't Pharo recognize recursive structures in some way? > > > I'm asking because I'm coming from a Python world, which is very similar to > smalltalk in some manners and I'm trying to make a big picture comparison in > my head. > > 1. I know that this doesn't really compares to Pharo which is a graphical > environment, but in python you can always hit Ctrl-C and break the > statements that block... If Alt/Cmd + . doesn't work, then something went really wrong. > >>>> while True: > ... pass > ... > ^CTraceback (most recent call last): > File "<stdin>", line 1, in <module> > KeyboardInterrupt >>>> > > Shouldn't the UI thread always be responsive? > No. > 2. And Python recognizes recursive structures: > >>>> a = [] >>>> a > [] >>>> a.append(5 > ... > KeyboardInterrupt >>>> a = [] >>>> a > [] >>>> a.append(5) >>>> a > [5] >>>> a.append(a) >>>> a > [5, [...]] >>>> a[0] > 5 >>>> a[1] > [5, [...]] >>>> a[1][1][1][1][0] > 5 >>>> > > > Don't get me wrong, I'm not trying to start a language war :) I wouldn't got > to page 171 if I'm not really interested in Smalltalk :-D I'm just trying to > get a clearer vision if these are some things that are there for some reason > (design decision), or they are just not yet implemented, or they cannot be > implemented for some other reasons? > Since the current code doesn't handle recursive structures, there's probably none in the image, and it still works. This makes me think that recursive structures are not that important in smalltalk. Fixing all the issues properly and without performance penalty may take a lot of effort. Levente > Thank you in advance for your time :), > Viktor >

Jan. 20, 2010

Re: [Pharo-project] About DecompilerTests >> decompilerDiscrepancies

by Michael Roberts

IIRC this suite is fairly specialised as part of eliot's closure work. I think we disabled it from running because we did not have time to fix it. I don't have an image at the moment but it would be better to leave it alone if you can until someone can study the decompiler in depth. Unless Eliot can comment? Cheers mike On Tuesday, January 19, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi folks: does someone know what is this method for ? > > In my case, it has included the message saveImageSegmentsÂ Â which I rename it to saveImageSegments: > > So...what should I do ? I put saveImageSegments:Â instead of saveImageSegmentsÂ or I just remove it from there? > > Thanks > > Mariano >

Jan. 20, 2010

Re: [Pharo-project] how to get nice native fonts in 1.0

by Mariano Martinez Peck

Be aware need a "Fonts" folder if you don't have DejaVu isntalled in your OS. Stef, which image are you going to use ? PharoCore, PharoDev, Seaside one click ? On Wed, Jan 20, 2010 at 9:27 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Wed, Jan 20, 2010 at 8:48 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > I have to give some demos of seaside today and I would like to have nice > fonts in 1.0 > > and I cannot find the preferences to say that the fonts can be looked up > on my disc. > > and I'm looking for some nice combination (but the code snippets on the > wiki do not work). > > FreeTypeFontProvider current updateFromSystem. > > font := LogicalFont familyName: 'DejaVu Sans' pointSize: 10. > codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. > titleFont := LogicalFont familyName: 'DejaVu Sans' pointSize: 11. > > Preferences > setListFontTo: font; > setMenuFontTo: font; > setCodeFontTo: codeFont; > setButtonFontTo: font; > setSystemFontTo: font; > setWindowTitleFontTo: titleFont. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010

Re: [Pharo-project] how to get nice native fonts in 1.0

by Damien Cassou

On Wed, Jan 20, 2010 at 8:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I have to give some demos of seaside today and I would like to have nice fonts in 1.0 > and I cannot find the preferences to say that the fonts can be looked up on my disc. > and I'm looking for some nice combination (but the code snippets on the wiki do not work). FreeTypeFontProvider current updateFromSystem. font := LogicalFont familyName: 'DejaVu Sans' pointSize: 10. codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. titleFont := LogicalFont familyName: 'DejaVu Sans' pointSize: 11. Preferences setListFontTo: font; setMenuFontTo: font; setCodeFontTo: codeFont; setButtonFontTo: font; setSystemFontTo: font; setWindowTitleFontTo: titleFont. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by Stefan Marr

You mean how their approaches compare? (I would guess, there is no direct involvement of people in both projects.) PyPy is a generator approach, your language specification i.e. the interpreter is used to generate a VM. You use a high-level language i.e. RPython to implement a classic interpreter, which is then transformed by a powerful tool-chain to your C implementation (and a JIT). Stuff like GC is just generated for you. The result is one specific VM, which is generated for your language. With Parrot it is much like with a classic VM like JVM or CLR/.NET. You are using one existing VM. Language developers use the Parrot Assembly language (PASM) or the Parrot Intermediate Representation (PIR) which can then be compiled to the bytecode set. Furthermore, they can extend the bytecode set with their own instructions (primitives). So, you are basically compiling your target language while using all the runtime features of the Parrot VM. So, here the 'power' is in the VM, not in a transformation tool chain. Best Stefan On 20 Jan 2010, at 09:02, StÃ©phane Ducasse wrote: > stefan > > do you know how this is linked with pypy? > > Stef > > On Jan 20, 2010, at 8:50 AM, Stefan Marr wrote: > >> >> On 20 Jan 2010, at 06:12, Miguel Enrique CobÃ¡ Martinez wrote: >> >>> Parrot has just been released: >>> http://www.parrot.org/news/2010/Parrot-2.0.0 >>> >>> I would like to know, from the VM experts from the community, if this VM >>> can be used to run Smalltalk. >> Well, as someone mentioned, there seems to be Smalltalk implementation... >> >> But, probably it is hard to get it fast. >> Parrot uses a very unique approach. >> Actually, they try to provide a language runtime for all kinds of languages, and the right tools to build them: http://www.linux-mag.com/cache/7373/1.html >> >> Eliot mentioned primitives, well, there is no concept of a primitive in Parrot. >> Instead, they have a unification of bytecodes and primitives. The idea is, to give you the tools to develop the bytecode you need for your language, which can be loaded dynamically during execution. >> It will be interesting to see, how they can get their JIT fast with this strategy. >> >> Best >> Stefan >> >> >>> The site says that >>> >>> "Parrot is a virtual machine aimed at running all dynamic languages.". >>> >>> but I don't know anything about VM so this sounds to me a bit like black >>> magic. >>> >>> Is there something in the squeak vm that is specific to the way >>> smalltalk works or a generic virtual machine (maybe with a upper layer >>> understanding Smalltalk specifics) can be used. >>> >>> Thanks for the answers >>> >>> -- >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 3956 >> Fax: +32 2 629 3525 >> >> >> _______________________________________________ >> 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 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

Jan. 20, 2010

Re: [Pharo-project] Beta Testing

by StÃ©phane Ducasse

yes ! On Jan 20, 2010, at 9:13 AM, Mariano Martinez Peck wrote: > > > On Wed, Jan 20, 2010 at 2:38 AM, Michael Litchard <michael(a)schmong.org> wrote: > Hi, I'm running NetBSD-current on AMD 64 bit. If that's useful to you > I'd like to be a beta tester. > > > > Of course, thank you very much :) > > I have added you here: http://code.google.com/p/pharo/wiki/ListOfBetaTesters > > Take into account that we will send and email with a tag [BetaTesting] or something similar > > THis week / weekend , I will probably release a new Dev image which may be VERY similar to the official 1.0 release. So, it would be cool to have a lot of testing. > > Cheers > > Mariano > > > > Michael Litchard > > _______________________________________________ > 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

Jan. 20, 2010

Re: [Pharo-project] Nabble

by Geert Claes

Moved it under "Pharo-Smalltalk". Mind you, I would like to add that I would prefer to see "Seaside" (and AIDAWeb for that matter) to see under "Smalltalk" rather than "Squeak" -- View this message in context: http://n2.nabble.com/Nabble-tp4416405p4425244.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 20, 2010