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

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

by Michael Roberts

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. 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. I'll take a look later on. 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 >

Jan. 20, 2010

Re: [Pharo-project] Beta Testing

by Mariano Martinez Peck

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 >

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by StÃ©phane Ducasse

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

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by Stefan Marr

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

Jan. 20, 2010

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

by StÃ©phane Ducasse

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. and I'm looking for some nice combination (but the code snippets on the wiki do not work). Stef

Jan. 20, 2010

Re: [Pharo-project] about fast lineDo and...

by StÃ©phane Ducasse

ok I understand. I will keep your energy for the important one. but since I'm nearly the only that have a look at fixes in squeak may be I will simply just stop to look at them because the community does not seem to interested in getting them or producing them for pharo. Stef On Jan 20, 2010, at 8:27 AM, Nicolas Cellier wrote: > Don't know if I'll have time, but changes are fairly easy to grab > (independent of each other). Ok > > Nicolas > > 2010/1/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi nicolas >> >> I saw that you commit some speed up for lineending to the squeaktrunk and I would love to have them >> since in moose we are computing a lot LOC :) >> By any chance could we get the same in pharo? >> Else I will harvest them. >> >> 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

Jan. 20, 2010

Re: [Pharo-project] AddMethodRefactoring>>preconditions

by Lukas Renggli

> You are right Lukas, what i proposed wasn't a refactoring at all! > > Thanks for the info and the example. It's perfect that people critically look at the refactoring code. There are certainly bugs. The code base is large, highly dependent on the underlying reflective system and does quite a few non-trivial things. Just yesterday I found two subtle bugs in the refactoring model while creating tests for the OB-Refactoring integration. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 20, 2010

Re: [Pharo-project] about fast lineDo and...

by Nicolas Cellier

Don't know if I'll have time, but changes are fairly easy to grab (independent of each other). Nicolas 2010/1/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi nicolas > > I saw that you commit some speed up for lineending to the squeaktrunk and I would love to have them > since in moose we are computing a lot LOC :) > By any chance could we get the same in pharo? > Else I will harvest them. > > Stef > _______________________________________________ > 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] AddMethodRefactoring>>preconditions

by Fernando olivero

You are right Lukas, what i proposed wasn't a refactoring at all! Thanks for the info and the example. Fernando On Jan 19, 2010, at 6:33 PM, Lukas Renggli wrote: > Hi Fernando, > >> Lukas, i stumbled upon a strange behavior using the refactoring engine. >> >> When adding a method, the precondition checks if the class or any super class defines the method to be added. >> >> It must only ask if the class directly defines it. >> >> AddMethodRefactoring>>preconditions >> | selector method | >> method := RBParser parseMethod: source >> onError: >> [:string :position | >> ^RBCondition >> withBlock: [self refactoringError: 'The sources could not be parsed']]. >> selector := method selector. >> selector isNil ifTrue: [self refactoringError: 'Invalid source.']. >> ^(RBCondition definesSelector: aSelector in: aClass : selector in: class) > > I don't think this is a correct change, because with this modification > the AddMethodRefactoring is not a refactoring anymore. You can only > add a method to a class without changing the behavior if that selector > is not defined in the hierarchy. Furthermore your change breaks the > unit tests, namely RBAddMethodTest. > > I don't know why you think this is a bug? If you use the refactoring > engine to generate code then you shouldn't use the > AddMethodRefactoring, but the AddMethodChange. For example to add some > arbitrary methods to an arbitrary class you could use (and this is > obviously not a refactoring, but some random change): > > | model | > model := RBNamespace new. > (model classNamed: #Morph) > compile: 'asMorph ^ nil' > classified: #(accessing). > model changes open > > In the above example the call to #compile:classified: creates the > AddMethodChange object that you then see when you open the changes > log. > > Cheers, > Lukas > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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 about O2 dependencies

by StÃ©phane Ducasse

We have it have a look at Gofer fetch and push Stef On Jan 20, 2010, at 3:55 AM, Serge Stinckwich wrote: > Very interesting explanations indeed ! > What would be nice is to have similar functionalities than GitHub for > SqueakSource and more community aspects. > > 2010/1/20 Lukas Renggli <renggli(a)gmail.com>: >> 2010/1/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> >>> >>> On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger >>> <roethlis(a)iam.unibe.ch> wrote: >>>> >>>>>> Ok. Good. Right now, the Pharo community decided to use Lukas' >>>>>> repository instead of Colin's one, but I guess it can be merged. Lukas ? >>>> >>>>> I find it unfriendly to merge into a foreign repository -- pull, fork and >>>>> merge in your own repository. And eventually ask the maintainer to merge the >>>>> code. >>>> >>>> I'm confused. What is the right process to update OB for Pharo now? In >>>> Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this >>>> gonna change now? Where should I commit a patch to OB now, to Colin's, to >>>> Lukas' repo, somewhere else? >>>> >>>> Maybe best would be to have a non-personal repo on squeaksource which can >>>> be used by all OB developers and from where Pharo takes the code? >>>> >>>> David >>> >>> I am confused too. Actually, this is exactly what I asked when people >>> suggested to use Lukas' OB. >> >> Public code repositories do not work. I learned that with Seaside, and >> we all saw that in all its ugliness with OmniBrowser. >> >> If this is a popular project in a public repository people will commit >> changes to that repository. Some of the committed changes are ... >> >> - untested >> - break existing tests >> - break the architecture >> - break other code >> - put into the wrong package >> - only working for the committer >> - badly formatted or commented >> - depend on non-existing code >> - ... >> >> Now, if nobody constantly observes that repository and cleans it up, >> you have an enormous mess. There are basically dozens of forks and >> nobody knows what works, what is broken, what is official, what to >> load, what to use, where to continue with development, etc. >> >> And that's not even the end of it. The next thing that happens is that >> people start to merge: so random versions with random changes are >> merged in a random order. As a result the problems and bugs multiply. >> >> After I saw GitHub, I realized that in the open-source world only >> read-only code repositories work. The cool thing is that Monticello >> and Git have a very similar model, so we just have to adapt their >> process: >> >> - Every open-source project has a public read-only repository. Only >> core contributes that trust each other can commit into this >> repository. >> >> - If I want to change something, submit a bug-fix, or an enhancement I >> simply fork the complete code base and commit it into my own >> repository. >> >> - As a nice open-source contributor I ask one of the official >> maintainers to merge my changes by pointing them to my repository: >> >> - If they like the changes, they will merge them into the official >> repository. >> >> - If they don't like the changes, that's fine too. I have my own >> repository and can use the code in there. >> >> That's it. It is simple and works really well. >> >> That's why my OB repository is read-only. I know that the code in >> there passes all tests and that it does exactly what I want. Please >> fork it, improve it, fix things, etc. If I learn about the changes and >> if I like them I will merge them (that's what I did with some of the >> O2 code). I do not commit my changes to Colin's repository though, if >> he wants the code he can pull it (that's what he did in the past too). >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > > _______________________________________________ > 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