December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Let's hire a Pharo developer

by Guido Stepken

Hi Marcus, hello to all! You wrote: > Sometimes I think there is something I fundamentally don't understand... In history, the fastest growing opensource communities consisted of partly employed professionals, who invested lots of their spare time in driving a software package forwards, hoping, that, one day, there will be a payoff in terms of: a) getting known as specialist to get hired b) learn new concepts to make yourself or your students happier (adademic research) :-) c) join a group to build a commercial or adequate product to found a enterprise on, become shareholder, go to stock exchange, become rich d) mixture of above In any case - there has to be a "coherent concept", a realistic future or idea, why one should invest into such thing on a descending branch like Smalltalk. For Squeak/Etoys/Scratch it's quite clear. Teaching programming to children. IMHO, there is no better software to teach childen. Alan Kay as community organizer and figurehead leading a crowd of followers. There is a community of people, driving that stuff slowly, but steadily forward. In germany its HPI investing lots into building up knowledge in Smalltalk/Squeak/EToys. Money comes from SAP founder. Very idealistic man. The situation of Pharo reminds me a bit of Dolphin Smalltalk: Where's the customer who urgently needs such a product? There are a lot of free competitors around: Smalltalk/X, GNU, Little, Vista ... It's not easy to explain the differences of concepts behind those smalltalks. But it's much harder to explain, why we need to invest more time and sink more money into a (commercially) "sinking boat" of technology. I could make out a few "trends" in software technology since some time: * Parallel computing. (Smalltalk rather has a structure of a human brain, no chance to parallelize, wrong algorithms behind) * In Form Matics: Bringing everything in a form of "XML", "XAML", "FXD" "XUL", "SVG", "KXML" ... e.t.c. A fatal trend. Programmers today, expecialy those working in JAVA or C# ... have to bother much more about bringing data "in form", than to do something really productive. * Standards: Important is the standardisation of data (data exchange standards", not so much the toolkit or the programming language, you use. See Java: Groovy, Jython, JRuby or Microsoft .NET language park. * Animated GUI's, Touch: With the upcoming of Apples "touch technology" (concepts from stanford university) a new trend has come ... animated, moving selectors, menus with - OpenGL ES hardware acceleration on 2W power consuption processors (TI OMAP3 , 4). * The end of SQL-92 databases: There is a clear trend towards OODBMS and persistence. * Cloud computing: In former times called "UNIX terminals" now replace "FAT Clients". * WEB OS coming up: Palm PRE, Google OS, all based on JAVASCRIPT. * Desktop applications go to portable computers. (Mailclient on desktops in huge enterprises will one day be replaced by new software technologies on portables) * Computer games go Shockwave/Flash. JAVA, SILVERCLOUD, WPF, SQUEAK Plugin laying far behind. * Software/commuications standards and technologies go into cars: AutoSAR standard soon will replace proprietary technologies of car manufacurers. One trend, perhaps the most important trend is still unbroken: * Each computer professional will only recommend or suggest that technology that keeps himself employed and busy for long, long time. Who has invented those trends? Still APPLE, IBM, SUN, ORACLE, MICROSOFT. Today one standard is still vacant. Portables OS and GUI. Who will make the run? Perhaps Microsoft, perhaps GOOGLE, perhaps Nokia/Siemens, perhaps Samsung ... who knows? Hundreds of millions of dollars are being inwasted in new GUI prototypes ... IMHO one standard will fall in a few years: INTEL Processors. Asia with its billion of people need "high performance, low power consuption" standards. ARM and MIPS, IBM, FreeScale, TI will make the run. And: Linux will make the run as basic platform for all new technologies mentioned above. But: I still can't figure out, where exactly Pharo or Smalltalk as software technology could occupy a vacant market niche or even set standards. regards, Guido Stepken -- View this message in context: http://n2.nabble.com/Let-s-hire-a-Pharo-developer-tp4161222p4162145.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 14, 2009

Re: [Pharo-project] This interpreter (vers. 6502) cannot read image file (vers. 6504).

by Monty Kamath

My bad. I'm using Squeak-3.10-1.i686-pc-linux-gnu.tar which is an old VM. Will this old vm work with old images Squeak images? Thanks, Monty -- View this message in context: http://n2.nabble.com/This-interpreter-vers-6502-cannot-read-image-file-vers… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 14, 2009

[Pharo-project] This interpreter (vers. 6502) cannot read image file (vers. 6504).

by Monty Kamath

I'm trying to run my Pharo image on CentOS using Squeak-3.11.3.2135-linux_i386.tar.gz which I think is the latest linux vm. When I do I get this: This interpreter (vers. 6502) cannot read image file (vers. 6504). Press CR to quit... This doesn't happen with my older Squeak image. Also, this doesn't happen on Windows with the Pharo vm and my Pharo image. Can someone point me to the vm I should be using? Thanks, Monty -- View this message in context: http://n2.nabble.com/This-interpreter-vers-6502-cannot-read-image-file-vers… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 14, 2009

Re: [Pharo-project] package documentation viewer

by csrabak＠bol.com.br

Em 13/12/2009 19:00, Lukas Renggli <renggli(a)gmail.com> escreveu: > > Is there another search string or way to detect other empty comments? > Smalltalk allClasses select: [ :class | class organization > classComment isEmpty ] Lukas, Your way is clever (I didn't know ClassOrganizer until this exchange)! OTOH, it rises all the numbers: +--------+-------+-------+ | Image| update|result | | | | | +--------+-------+-------+ |1.0-dev | 10502 | 1831| +--------+-------+-------+ |1.1-core| 11098 | 703| +--------+-------+-------+ | 1.1-dev| 11098 | 1795| +--------+-------+-------+ I think I'll open an issue in the tracker. -- Cesar Rabak

Dec. 14, 2009

Re: [Pharo-project] Let's hire a Pharo developer

by Marcus Denker

On Dec 13, 2009, at 10:47 PM, alesch wrote: > > What do you think about hiring a developer to work exclusively and full time > on Pharo? ... > I'm the first one in the list. Who else? > I would be in. But I doubt that there would be enough people who would do this. There are many things that one would normally think would be logical to do. E.g, you have a company that uses a plattform for all your bussiness. Wouldn't you invest into it to secure your future? The Answer of all companies in the Squeak community the last 10 years was: "No". Or, you are an employee at such a company. Wouldn't you want to invest a bit of time and energy into the Plattform to make sure that, if the compay lays you off, you can find other employment in waht you did the last X years? The answer of all these Employees and Consultants in the Squeak Community was: "No, I am not payed for that". Sometimes I think there is something I fundamentally don't understand... Marcus

Dec. 13, 2009

Re: [Pharo-project] [update 1.1] #11098

by Marcus Denker

On Dec 13, 2009, at 11:26 PM, Marcus Denker wrote: > 11098 > ----- > > Issue 1596: DNU when entering a keystroke in the world > Issue 1598: Preferences migration part9 > > * migrate "halo" and "menu" groups hmm... the menues look a bit strange after the update. > * remove ColorTheme class > * remove SmalltalkImage>>setPlatformPreferences > * make the "about" dialog open at a fixed position (near top left)

Dec. 13, 2009

[Pharo-project] [update 1.1] #11098

by Marcus Denker

11098 ----- Issue 1596: DNU when entering a keystroke in the world Issue 1598: Preferences migration part9 * migrate "halo" and "menu" groups * remove ColorTheme class * remove SmalltalkImage>>setPlatformPreferences * make the "about" dialog open at a fixed position (near top left)

Dec. 13, 2009

[Pharo-project] A reengineering the CompiledMethod trailers

by Igor Stasenko

Hello guys, please take a look at changeset i just uploaded: http://bugs.squeak.org/view.php?id=7428 There is an initial implementation of CompiledMethodTrailer with some test coverage. My motivation behind this is simple: 1. no more poking with raw bytes, like this: holdsTempNames "Are tempNames stored in trailer bytes" | flagByte | flagByte := self last. (flagByte = 0 or: [flagByte = 251 "some source-less methods have flag = 251, rest = 0" and: [(1 to: 3) allSatisfy: [:i | (self at: self size - i) = 0]]]) ifTrue: [^ false]. "No source pointer & no temp names" flagByte < 252 ifTrue: [^ true]. "temp names compressed" ^ false "Source pointer" or this: endPC "Answer the index of the last bytecode." | size flagByte | "Can't create a zero-sized CompiledMethod so no need to use last for the errorEmptyCollection check. We can reuse size." size := self size. flagByte := self at: size. flagByte = 0 ifTrue: ["If last byte = 0, may be either 0, 0, 0, 0 or just 0" 1 to: 4 do: [:i | (self at: size - i) = 0 ifFalse: [^size - i]]]. flagByte < 252 ifTrue: ["Magic sources (temp names encoded in last few bytes)" ^flagByte <= 127 ifTrue: [size - flagByte - 1] ifFalse: [size - (flagByte - 128 * 128) - (self at: size - 1) - 2]]. "Normal 4-byte source pointer" ^size - 4 2. method's trailer can be used for storing a variety of stuff, not just source pointer or temps names. And it will be easy to add new kinds of trailers. A most useful, as to me, and which i've added initially is: - being able to embed the source code in trailer, so a compiled method and its source lives together in image. Some of you have expressed this idea before, so here it is. - being able to retrieve the method's source using other way, than through SourceFiles or embedded in trailer. I added two kinds of trailers for that: - get method's source by class+selector where it installed to. - get method's source by class+some string identifier - yours. Please tell me, what kind you want to have in addition. 3. a source pointer could surpass the 32Mb limit. A CompiledMethod already can encode a source pointer value of any size. Its now only a matter of fixing the source pointer encoding logic to enable having .source and .changes files above 32Mb. Please, review my code and send me your comments and wishes. At next stage i will create a changeset which will put this stuff in use, as well as cleanup lots of places in CompiledMethod and compiler/decompiler. -- Best regards, Igor Stasenko AKA sig.

Dec. 13, 2009

Re: [Pharo-project] Let's hire a Pharo developer

by StÃ©phane Ducasse

> I'm new in the Smalltalk community, and even newer in Pharo. > If the following has been discussed before, I have not found it in the > archives. > > What do you think about hiring a developer to work exclusively and full time > on Pharo? would be a nice model now I'm not sure we could get 100 paying 10 Euros a month even if this is really tempting. > At ESUG'09 there were about 250 people, and Smalltalks'09 had about the same > number of attendees. > 100 people paying â¬10/month yields â¬1000/month. > I'm not sure, but I think that it is a good salary in Argentina. > > Let's take advantage (in the good sense) of the vibrant Smalltalk community > in Argentina, and the actual state of the euro/peso. For europeans, â¬10 is > about two beers. > > Make it an automatic withdrawal, so once you've taken the desition, you > never think about again. > > I'm the first one in the list. Who else? > > -- > View this message in context: http://n2.nabble.com/Let-s-hire-a-Pharo-developer-tp4161222p4161222.html > 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

Dec. 13, 2009

Re: [Pharo-project] FAME: support for multiple inheritance?

by StÃ©phane Ducasse

> Hello list: > > Does FAME supports mutltiple inheritance? > I guess the answer is NO, but I thought I would ask to be sure. You mean for describing or for generating code? FAME is really simple so may be this is still worth to extend it :) > The scenario is a description language that today is implemented as 4 UML > profiles, on top of each other. > This profiles are then realized with Eclipse EMF (ecore), and Java. > Quite a heavy framework for prototyping, =) Oh yes. > > I'm evaluating the possibility of replacing this stack with FAME. May be you could extend FAME and see if you cannot generate traits. > > Thanks in advance! > > > -- > View this message in context: http://n2.nabble.com/FAME-support-for-multiple-inheritance-tp4161084p416108… > 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

Dec. 13, 2009