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

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by Richard Durr

No, it's not. I would be far more valuable to have modularized images though: Just like Next/Apples Nibs or Bundle-mechanism. These image-modules would be edited from a development-image-bundle. They could be used to form stand-alone applications already clean of the development code or libraries that contain only a diff to the base classes, these library-images could then be combined to form more complex images. They could also contain their own namespaceâ¦ and they would replace the non-modelling packaging mechanism, but I digressâ¦ ^^ | packageWorkedOn | packageWorkedOn := Browser newPackageNamed: 'Calculator'. packageWorkedOn importPackage: 'Seaside'. "Create code in the Browserâ¦" packageWorkedOn saveAsMonticello. packageWordedOn saveAsPackage. packageWorkedOn saveAsApplication. or something like that â¦ ^^ On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <epicfan(a)gmail.com> wrote: > > jarober says: > >>The reason these "Smalltalk for .NET" and "Smalltalk for the JVM" >>projects never seem to come off is simple - Smalltalk isn't just flat >>text in an editor. Â Smalltalk is the entire interactive environment. >>It would be fairly simple to get a syntax parser, but it wouldn't be >>Smalltalk. Â It would be Ruby or Python with Smalltalk syntax. >>Somewhat useful perhaps, but not really Smalltalk. > > :( > > Hopefully it would have sufficient knowledge to be able to do something > thus. > > Sorry, but I believe that it is the way that had to take commercial > Smalltalk. It surprises to me that Cincom and company do not see it. > > Regards. > -- > View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 5, 2010

Re: [Pharo-project] Sugar Theme

by Bert Freudenberg

On 03.04.2010, at 13:28, Hilaire Fernandes wrote: > > Michael Rueger a Ã©crit : >> On 4/3/2010 11:09 AM, StÃ©phane Ducasse wrote: >>> did you check on the etoy image? I imgaine that they have their own >>> repository? Sye >> AFAIK they don't use Monticello... > > Okay. > > By the way, does this gettext layer need plugin or is 100% smalltalk code? > > Hilaire It's 100% Smalltalk. Korakurider did a great job. And we do have translations for all the Smalltalk tools, too. In fact, we need to work on splitting up that one huge file with > 4000 translated phrases (>25000 words). http://translate.sugarlabs.org/projects/etoys/ Btw, we do not use Monticello yet, though we're working on switching (the packages on source.squeak.org/etoys are work in progress, not usable yet). - Bert -

April 5, 2010

[Pharo-project] [update 1.1] #11309

by stephane ducasse

11309 ----- - Issue 2271: Scanner doesNotUnderstand: #ambiguousSelector:inRange: 1) Fix http://code.google.com/p/pharo/issues/detail?id=2271 which is also http://bugs.squeak.org/view.php?id=7491 2) replace slow asSortedCollection with faster asArray sort (from Squeak) Note that Behavior of 1@-1 is different from Squeak. Squeak favours backward compatibility in case of ambiguity. Pharo always send @- - Issue 2277: requestorOffset initialization is out of order - Issue 2275: URI comment + tests - Issue 2278: Obsolete class in 11308 Stef (I'm in house renovation mode - painting... so I will integrate a bit less frequently during the holidays).

April 5, 2010

[Pharo-project] offList

by StÃ©phane Ducasse

This fix is important if somebody knows if the solution proposed by nicolas is ok. please let us know http://code.google.com/p/pharo/issues/detail?id=2276 Stef

April 5, 2010

Re: [Pharo-project] Linux VM microbenchmarks

by Bryce Kampjes

On Sat, 2010-04-03 at 22:19 +0200, Hilaire Fernandes wrote: > Laurent, > > I runned the same benchmark with Exupery, here is > > Exupery > 202371541 bytecodes/sec; 5948654 sends/sec > 201574803 bytecodes/sec; 5948654 sends/sec > 201416207 bytecodes/sec; 5933632 sends/sec > 202531645 bytecodes/sec; 5903814 sends/sec > 201892744 bytecodes/sec; 5938631 sends/sec > > > -O2 (compiled source code from the archive you provided) > 87372013 bytecodes/sec; 4436220 sends/sec > 86544962 bytecodes/sec; 4501376 sends/sec > 86253369 bytecodes/sec; 4507132 sends/sec > 86253369 bytecodes/sec; 4487049 sends/sec > 87372013 bytecodes/sec; 4498503 sends/sec > > You better check with Bryce. The Exupery build is just whatever ./config/configure decides to use, nothing special here. I do make sure that the gawk gnuification runs. It's a very vanilla but a bit dated C VM build environment. Bryce

April 5, 2010

Re: [Pharo-project] [squeak-dev] Re: A small idea how to get closer to hardware with small efforts :)

by Igor Stasenko

On 5 April 2010 15:42, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Mon, Apr 05, 2010 at 03:13:51PM +0300, Igor Stasenko wrote: >> Here the proof of concept implementation. > > >> So, here the questions, which i like to be answered: >> 1. reserve a numbered primitive > > Probably a named primitive in the interpreter is best, see comment in > John's new primitiveMicrosecondClock. I don't think that there is any > performance implication once the primitive name has been resolved once. > this is true, but numbered primitive could be inlined into an interpret() loop. Then this will make some difference :) >> 2. discuss the calling convention >> 3. add a 'platform id' code to VMMaker, and let language side know , >> on which platform id VM currently runs on (through additional >> primitive) > > I'm not sure how to handle #3, but there are a lot of different CPUs > and operating systems out there, not to mention all the different modes > of say an Intel CPU. So it may not be trivial to answer the question > "can this snippet of compiled code be executed in my current runtime > environment". > Well, a 2 bytes for code gives us 65536 variants. If this is not enough, we could use 32 bits for platform id code. Also, i thinking , maybe we could use masks for platform id, so, then one could generate/use the same native code for multiple kinds of OS-es. But then , a number of variants will be much more limited, because platform id will be treated as a bit field, instead of integer value. > Dave > > > -- Best regards, Igor Stasenko AKA sig.

April 5, 2010

Re: [Pharo-project] [squeak-dev] A small idea how to get closer to hardware with small efforts :)

by Igor Stasenko

On 5 April 2010 16:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > igor > > I'm confused. > Do you want to write C code in our smalltalk editor? (as in Smalltalk/X) err.. no. why i would want that, if i can just generate native code directly? We could use Exupery for generating it, with slight modifications. Or implement different native code generator. > Where the native code is coming? > Who compiles it? > Can I edit it? > There is no any implications where the native code comes from. It could be from compiler, implemented in smalltalk, or may be stored in some file.. not really matters. And yes, you can edit the code and generate it dynamically. If you look at example of how i did run a native code routine, it creates a native code on the fly, code := #(184 85 0 0 0 195) asByteArray. trailer nativeCode: code platformId: 1. method := (self class methodDict at: #theStub) copyWithTrailerBytes: trailer. and then runs it, by invokind a generated method. Here, the #(184 85 0 0 0 195) is an x86 instructions: mov eax, (42 << 1 +1) ret so, when you run it, a native routine returns a 42 smallinteger. > Do you have a scenario in mind to help understanding what is your vision behind your suggestion? > Stef > > On Apr 5, 2010, at 10:13 AM, Igor Stasenko wrote: > >> Hello again, >> >> it is about running a native code , stored in compiled methods. >> >> All we need is: >> >> a) allow code execution for object memory. On most platforms this is >> trivial - just pass additional flags to virtual memory allocation >> functions. >> b) add a single primitive 'call a native code' >> c) use a special compiled method trailer, which will store the native >> code inside itself >> >> Then we could place any native code inside a compiled method and use a >> single primitive to run this code. >> This is quite simple thing, given that both pharo and squeak adopted >> method trailers, so >> a primitive, before running the code, needs few checks: >> - a method's trailer format is valid (we could reserve a terminal >> byte value for that) >> - a native code, placed inside a method trailer is targeted for same >> platform as currently running on >> >> if not, then primitive will simply fail, and interpreter will run the >> method's bytecode, which , depending on a situation, can check if it >> can recompile the code >> (if platform doesn't match) or use a workaround. >> The only limitation of such approach, that native code, placed in >> compiled method should be relocate-agnostic, i.e. >> never use absolute jumps, only relative ones and so on. >> >> Also, we could force, that code using a specific calling convention, >> so it will be easy to fetch values from stack and other useful stuff >> from interpreter/object memory (like passing an interpreterProxy >> pointer). >> This could be a good answer in generating a trampoline code for >> FFI/Alien on the fly. >> >> What you think? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 5, 2010

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by nullPointer

jarober says: >The reason these "Smalltalk for .NET" and "Smalltalk for the JVM" >projects never seem to come off is simple - Smalltalk isn't just flat >text in an editor. Smalltalk is the entire interactive environment. >It would be fairly simple to get a syntax parser, but it wouldn't be >Smalltalk. It would be Ruby or Python with Smalltalk syntax. >Somewhat useful perhaps, but not really Smalltalk. :( Hopefully it would have sufficient knowledge to be able to do something thus. Sorry, but I believe that it is the way that had to take commercial Smalltalk. It surprises to me that Cincom and company do not see it. Regards. -- View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 5, 2010

[Pharo-project] A port of Pharo: Redline Smalltalk ...

by Torsten Bergmann

>Someone knows the posibilities of implement a Smalltalk environment in MONO >.NET? Read the comments from around 23th of March at http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/ca5… Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

April 5, 2010

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by StÃ©phane Ducasse

On Apr 5, 2010, at 7:27 PM, nullPointer wrote: > > Someone knows the posibilities of implement a Smalltalk environment in MONO > .NET? I see projects like > http://ajlopez.wordpress.com/2008/07/14/ajtalk-a-smalltalk-like-interpreter/ > or too > http://www.refactory.com/Software/SharpSmalltalk/ John brant is the father of the refactoring browser. He did this experience to understand the problem for example of integer representation and others Stef > > but I will like know the guruÂ´s opinion. > > Regards. > -- > View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1750615p1751812.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 5, 2010