February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] External Browser

by Hilaire Fernandes

Le 15/02/2011 03:50, Yanni Chiu a Ã©crit : > 1. In your shell terminal, do "env | sort > /tmp/env.shell" > 2. Tweak your Smalltalk code to do "env | sort > /tmp/env.smalltalk" > > See if the differences, if any, gives you any ideas about what's wrong. So far I can't see important differences with diff > You could also try to run a shell, and set up the environment to be > exactly the same as you found in env.smalltalk, then run your command, Do you know how to do that ? Thanks Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

Feb. 15, 2011

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by pharo＠googlecode.com

Comment #9 on issue 3620 by ryd...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 I don't think you'll be able to successfully push a change which would remove access to the preference in Squeak to the OCompletion repository. Probably better to change the Settings Browser UI to not display settings defined in both ways (<systemsettings> and <preference:category:...> )twice.

Feb. 15, 2011

Re: [Pharo-project] [COTDC] 12 - PluggableListMorphByItem

by Igor Stasenko

On 15 February 2011 19:03, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > "Essentially useless in its current form. Probably intended to eventually > deal with actual objects in the list rather than indexing/string-forms." every time i looking at those pluggableXYZ. and it always one thought don't let me rest: - we don't need them. They are implementing/perverting functionality of base widgets. Because for most of them, they addding no value comparing to base widgets, but just some extended interface(s) on top. > Regards, Gary > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by csrabak＠bol.com.br

Em 15/02/2011 17:03,Â Igor Stasenko < siguctua(a)gmail.com > escreveu: On 15 February 2011 19:23,Â wrote: > > Em 13/02/2011 21:21, Stephen Taylor < stephen.taylor(a)bom.gov.au > > > escreveu: Igor Stasenko wrote: > > > >> > >> >> You have some integers: 0 83 67 77 68 72 80 112 113 87 70 > >> >> 82. When a variable's value is equal to any of these... > >> > >> > Don't try to convince me that there are sort of problems which > >> > can be solved only by using case statement :) > > Igor's attitude, which I'll take as sample of a school of thought > > is dangerously similar to the one which in name of keeping certain > > aspects of Smalltalk "pure" or near to the origins has made its > > acceptance fall as the other aspects of the technology (OO, WIMP, > > etc.), made their way into other languages/platforms/technologies. > > > I am not opposed to innovations or cross-breeding techs. My purism > lies on simple principle: KISS. If something could be made simpler > without losing key features then it should done. Your KISS principle has to come at odds with another one, which was the reason why the construct was put in place: performance. This is called engineering, it is the art of trade off. > > > >> You didn't answer the question though. > > And then this: to the first concrete example, no complete answer > > comes out which we could check if the code construct is indeed > > only a syntactic sugar, or deserves incorporation in the toolset > > of the language... > > I don't see a need of explaining how to interpret a simple > translation without using caseOf: statement. You don't, because you already decided that what it is at stake doesn't matter for Pharo. I'm just trying to recap here: the construct is not here to mud the purity of a beatiful OO language nor be incentive to bad code smells. It has been put to solve a particular problem in a very specific part of the system. > > >> > First, get rid of these integers in your code. That's the > >> killer - yes, we can usually design around cases where > >> we'd use case constructs (though I'm not convinced they're the > >> spawn of the devil) but what about cases where we're interfacing > >> with external data sources and we don't get to redesign the whole > >> system to suit our needs? > > FWIW, this kind of need, namely having to take alternate actions > > due different integer codes is pretty common when interfacing with > > industrial boards, a lot of protocols use this as well and most of > > them are already in use, some even have international standards. > And i suspect that all these standards are properly documented, and > each signal/number having its description, so you can represent them > by names, not by numbers. > I may lost something, but how will you convert the numbers in names to start with? > > So the answer "redesign your world to fit our world-view" does not > > cut in... > > > I'm not asking you to redesign C world to fit smalltalk view. Use > each tool what it made for. What i asking is to not use a > microscope for hammering nails. Hammer is much better tool for that. > This statement is called in Informal Logic "the Fallacy of the False Analogy". > > Also, another argument I've seen in this thread which is pretty > >commonplace w.r.t. performance must be extirpated in our discourse: > >"the performance x to y slower than is very good considering > >{dynamic} languages (or similar statement)". > > Performance counts! > Sure. At some point if you train long enough you can hammer nail > using microscope much faster than using hammer. But that still > doesn't means that you doing it right :) As I already pointed out, your base reasoning is false, this is consequentially /non sequitur/.

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 15 February 2011 20:15, <csrabak(a)bol.com.br> wrote: > Em 15/02/2011 10:37, Igor Stasenko < siguctua(a)gmail.com > escreveu: > > Whereas I understand we are community of spirited and humorous programmers, I think that statements like: > >> I Â agree. Â Â Then Â probably, Â Pharo Â should Â move Â it Â to Â separate >> 'Crap-compat' package. > > Are not amenable to the "good energy" Stef is willing to have in the Pharo team. > >> Â ;-P > > And the emoticon puts a tongue! > > The 'nickname' brings a judgment of value which I think may stir more > feelings and doesn't bring anything useful to Pharo... > Yes, in this discussion i wearing hat of an asshole. With humor , of course. Hey.. i'm not killing people and don't burning heretics. Also, the importance of outcome of this discussion is too small for being taken too seriously. I can live with or without #caseOf: (but better without), so relax and have fun :) >> Â You don't need to remove Â #caseOf: implementation. I can stay. Just >> remove a compiler hacks for it :) >> Â P.S. i patched MessageNode class>>initialize to test if VMMaker can >> work without compiler Â support of caseof: and as Â it was expected it >> works quite well. >> Â I recompiled VMMaker package and then generated full source code of >> everything, and then built VM. No any errors. > > And what would be the results of Levente's benchmark? > I don't care. Read about hammer and microscope. > > -- > Best regards, > Igor Stasenko AKA sig. > > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by StÃ©phane Ducasse

On Feb 15, 2011, at 7:59 PM, Eliot Miranda wrote: > > > On Mon, Feb 14, 2011 at 11:00 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Eliot > > you use caseOf: for the generation of C in Slang and VM maker. > Now this means that > - it does not need to be inlined > > No. If it is not inlined the simulator will go *much* slower. e.g. > > CogVMSimulatorLSB>>byteAt: byteAddress > | lowBits long | > lowBits := byteAddress bitAnd: 3. > long := self longAt: byteAddress - lowBits. > ^(lowBits caseOf: { > [0] -> [ long ]. > [1] -> [ long bitShift: -8 ]. > [2] -> [ long bitShift: -16 ]. > [3] -> [ long bitShift: -24 ] > }) bitAnd: 16rFF > Does simulator needs to be fast? Then I have no problem that this code is in VMMaker. If this is essential. > - it could be packaged with VMMaker > > No. It needs to be in the compiler to be inlined. Why have you got on this hobby-horse? Absolutely not. There are a lot of stuff that can follow the same argument. And at the end we will have a system with a lot of stuff nearly used and more or less useful. I want Object to be cleaned. I want a clean compiler. I want to minimize our pain. and not having to decompile caseOf: = less pain less works less maintenance.... I want to have a real clean kernel > It is a non-issue. caseOf: ios not widelty used but extremely useful in certain circumstances. This has the feeling of a religious pogrom, not a rational approach to the system. This is what you believe but this is rationale. Why do we have 400 methods in Object, 800 in Morph (and we already removed a lot of them). > IIABDFI = If It Ain't Broke, Don't Fix It. No sorry are telling to marcus that instead of doing something cool he should burn his time on decompiler for a message that is used by 3 tools? Am'i hearing you saying that? Please let me know instead of telling me that I focus on the wrong stuff to fix. And breaking senders and implementors and probably pretty printing. Do we care about having a decent compiler? This is more than 2 years that I want a compiler with an open infrastructure so that we can have first class instance variables (like in CLOS since 1990). I want to have Maggrite like meta description integrated and I want daemons in less than 10 lines of code. Not copying a complete compiler like in Tweak. We prototyped first class instance variable with **no** runtime cost in one afternoon 2 years ago and this is still not our image. Why because there are fucking stuff everywhere. When do we really invent something new in this wonderful community or are we just doomed to stay doing fucking maintenance of CRAPPPPPPY code. Because let us face it this is about that. I'm doing pharo to move on and reinvent the system. If we do not reconsider past choices why do we need filesystems? It works no so do not fix it. Streams too, Morphic yes it works, browser (come on we are the only system on earth where Car inherits from Wheel - yes us the inventors of OOP - laughable - you should see some of our students they laugh a lot. Because Browser inherits from StringHolder.... So do we want that because if we want that. I'm off. > Are these two points correct? > > No, IMO, definitely not. > > > Stef > >

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 15 February 2011 19:59, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, Feb 14, 2011 at 11:00 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Eliot >> >> you use caseOf: for the generation of C in Slang and VM maker. >> Now this means that >> Â Â Â Â - it does not need to be inlined > > No. Â If it is not inlined the simulator will go *much* slower. Â e.g. > CogVMSimulatorLSB>>byteAt: byteAddress > | lowBits long | > lowBits := byteAddress bitAnd: 3. > long := self longAt: byteAddress - lowBits. > ^(lowBits caseOf: { > [0] -> [ long ]. > [1] -> [ long bitShift: -8 Â ]. > [2] -> [ long bitShift: -16 ]. > [3] -> [ long bitShift: -24 ] > }) bitAnd: 16rFF > so why not put it: ^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF ? Or this will be slower than caseOf: ? >> >> Â Â Â Â - it could be packaged with VMMaker > > No. Â It needs to be in the compiler to be inlined. Â Why have you got on this > hobby-horse? Â It is a non-issue. Â caseOf: ios not widelty used but extremely > useful in certain circumstances. Â This has the feeling of a religious > pogrom, not a rational approach to the system. Â IIABDFI = If It Ain't Broke, > Don't Fix It. This concept kinda appeal to me. >From other side, i am also strongly feel that house should be kept clean :) >> >> Are these two points correct? > > No, IMO, definitely not. > >> >> Stef >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by csrabak＠bol.com.br

Em 15/02/2011 10:37, Igor Stasenko < siguctua(a)gmail.com > escreveu: Whereas I understand we are community of spirited and humorous programmers, I think that statements like: > I agree. Then probably, Pharo should move it to separate > 'Crap-compat' package. Are not amenable to the "good energy" Stef is willing to have in the Pharo team. > ;-P And the emoticon puts a tongue! The 'nickname' brings a judgment of value which I think may stir more feelings and doesn't bring anything useful to Pharo... > You don't need to remove #caseOf: implementation. I can stay. Just > remove a compiler hacks for it :) > P.S. i patched MessageNode class>>initialize to test if VMMaker can > work without compiler support of caseof: and as it was expected it > works quite well. > I recompiled VMMaker package and then generated full source code of > everything, and then built VM. No any errors. And what would be the results of Levente's benchmark? -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 15 February 2011 19:23, <csrabak(a)bol.com.br> wrote: > Em 13/02/2011 21:21, Stephen Taylor < stephen.taylor(a)bom.gov.au > escreveu: > Igor Stasenko wrote: > >> >> >> You Â have some Â integers: 0 Â 83 67 Â 77 Â 68 72 Â 80 112 Â 113 87 Â 70 >> >> 82. When a variable's value is equal to any of these... >> >> > Don't try to convince me that there are sort of problems which can >> > be solved only by using case statement :) > > Igor's attitude, which I'll take as sample of a school of thought is dangerously > similar to the Â one which in name of keeping certain aspects of Smalltalk "pure" > or near to the origins has made its acceptance Â fall as the other aspects of the > technology (OO, WIMP, etc.), made their way into other languages/platforms/technologies. > I am not opposed to innovations or cross-breeding techs. My purism lies on simple principle: KISS. If something could be made simpler without losing key features then it should done. >> Â You didn't answer the question though. > > And then this: to the first concrete example, no complete answer comes out which we > could check if the code construct is indeed only a syntactic sugar, or deserves > incorporation in the toolset of the language... > I don't see a need of explaining how to interpret a simple translation without using caseOf: statement. >> Â > First, get rid of these integers in your code. >> Â That's the killer Â - yes, we can usually Â design around cases where >> we'd use case constructs (though I'm not convinced they're the spawn >> of Â the devil) Â but what Â about cases Â where we're Â interfacing with >> external data sources and we Â don't get to redesign the whole system >> to suit our needs? > > FWIW, this kind of need, namely having to take alternate actions due different > integer codes is pretty common when interfacing with industrial boards, a lot of protocols use this as well and most of them are already in use, some even have international standards. And i suspect that all these standards are properly documented, and each signal/number having its description, so you can represent them by names, not by numbers. > > So the answer "redesign your world to fit our world-view" does not cut in... > I'm not asking you to redesign C world to fit smalltalk view. Use each tool what it made for. What i asking is to not use a microscope for hammering nails. Hammer is much better tool for that. > Also, another argument I've seen in this thread which is pretty commonplace w.r.t. performance must be extirpated in our discourse: "the performance x to y slower than <baseline implementation> is very good considering {dynamic} languages (or similar statement)". > > Performance counts! Sure. At some point if you train long enough you can hammer nail using microscope much faster than using hammer. But that still doesn't means that you doing it right :) >One of the reasons we're working in Pharo is to bring its performance on par with competitive technologies. Â We're doing things to take out 'cruft', some to make the abstractions more elegant, but some are pragmatic which require depart of breaking 'pure' Smalltalk OO way of thinking. > > -- > Cesar Rabak > > >> >> >> Â Steve >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

Re: [Pharo-project] [Vm-dev] Cog builds on Hudson

by StÃ©phane Ducasse

I love these mails. Nice music to my hear......agility, reproducibility, control of complexity.... Imagine building a new vm each time a package changes. Is it not a dream? Imagine soon we will be able to know when aperformance degrades because of a change and all that based on git hub and a nice hudson server. So people will be able to modify their vms and plugin and manage their life and publish improvements. Simply gorgeous. I think that what is important besides making VM compiling more mainstream is that it gives a good signal to the outside world. Yes investors/inventors/people on the edge yes we have processes, yes we are concerned by quality, yes we are concerned by reproducibility,... Stef > I modified the Cog config made by Marcus to sync with my changes in scripts. > > https://pharo-ic.lille.inria.fr/hudson/view/Cog/ > > i also added a new target for building - Stack VM > (except that it not works now, because Hudson can't pick up the built > artifacts despite VM built successfully -- lets wait for Marcus to fix > that , since i'm not expert in Hudson :) ). > > Adding another two is also a piece of cake - just copy existing > configuration and change > destination directory and configuration class used for generating > sources and build config. > > The script i made for Hudson can work even for macs, > it takes 3 arguments: > - git repo url > - working subdirectory name where to place everything > - cmake configuration class name (which build to perform) > > that's all you need to build VM from scratch using Hudson > > -- > Best regards, > Igor Stasenko AKA sig.

Feb. 15, 2011