- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Enthousiasm is the main currency among developers

by Igor Stasenko

On 31 January 2012 16:16, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jan 31, 2012, at 12:10 PM, Frank Shearar wrote: > >> On 31 January 2012 14:44, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: >>> I agree whole heartedly after a month of Pharo being used as a tool for >>> newbies. >>> >>> a) Crashes... > > Make sure to run an up-to-date vm and image (and yes, the downloads are not up to date...) > > And it's important that people report problems. If problems are not reported, it is as if they > would not exist. > >>> b) Bugs in basic functionality: Morphic as well as in other places > Morphic is just crap. But what can we do else than slowly fixing what we see? > >>> c) The User Guide is not in synch with the current stable Pharo.. in simple >>> images of browsers.. > We just can't update pharo by example for every release... the day has just 24 hours. > But it is true that the version right now is far too old. (based on a horibly slow 1.0 with > a completely different browser...) > > > In general there are two options: > > Â Â Â Â -> give up and do something else > Â Â Â Â -> fix the problems, step by step. > there's third option: - give up and fix problems step by step :) -- Best regards, Igor Stasenko.

Jan. 31, 2012

Re: [Pharo-project] CogVM driver vs executable

by Schwab,Wilhelm K

Sig, Short answer: I ****think***** the answer is to look for the #moduleName as-given. Screen against absolute paths if you want; Ubuntu won't care. Ubuntu demands that libraries be registered (using sudo+dlconfig) to create a map that anyone can then read, either implicitly by loading the library or explicitly using dlconfig. It's suble, clever, and correct. What I do NOT know how to do is enforce that policy in the vm. I am fairly confident that I can guide you or another vm jock to a correct solution. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Tuesday, January 31, 2012 10:27 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] CogVM driver vs executable On 31 January 2012 16:10, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Thx for the reply, but as I said, I don't understand this library loading, or why it has to be so complicated. > me neither.. so i don't even care to read this topic carefully. i can't understand why we need such complex library lookup logic in VM ,and other "driver" mechanisms. i already proposed to move all this logic to image side, so at least we could have a direct control of what happening, as well as a good error handling in case of troubles. while at VM, there should be a simplest possible thing to stay, a function which takes a path to library and reports a handle to it if it loaded it or error code, why it cannot be loaded (file not found, lib file found but cannot be initialized etc). > I am all for putting the maximum possible amount of control in the image. > > In the mean time I saw that the driver is actually just a shell script ;-) (I knew that but I guess I forgot). > > My main question remains: why is this necessary since it works without the scipt just as well. > > Sven > > On 31 Jan 2012, at 11:00, Schwab,Wilhelm K wrote: > >> Sven, >> >> I'm not sure what to tell you. The "can't infer" message you are experiencing ***might*** be the one time the vm is actually telling what's wrong. If so, it's PROGRESS. Doesn't feel like that in your shoes, I know.... >> >> The bane of my existence is a silent failure (I dread those two word in that sequence...) of the vm to look in the right place. What did Nick suggest to me? strace, I think (it's in the archives). You might run under it to see if you can gain some insight; the tool in question does not pt >> >> DON'T LET THIS HAPPEN TO YOU<g>: the tool in question[*] logs its output to sterr(?), not stdout as one might expect. If you try it, use the -o option (I think) to direct to a file, then cat and grep are your friends. I remember "streaming" this into the archives, but I can't see them to check the facts. >> >> I solved my problem by noting where the vm was actually looking and making sym links to trick it (should not have to...) into working (very good). Let's all send kind thoughts to Sig - maybe he'll pull the search policy into the image, where it belongs. We will still want vm level logging (syslog etc.) in case the image can't run. >> >> SECURITY: Ubuntu gets it right (took me a while to realize same) by "forcing" us to use dlconfig to map names to libraries. I don't really understand it all, but I might be able to fake some useful answers if that is confusing. You might need to use dlconfig to "fix" Ubuntu, and then links to fool the vm into looking where it should. >> >> HTH, >> >> Bill >> >> >> [*] short term memory disorder<g>, which is precisely why we want informative errors reaching the Smalltalk code (and?)/OR(ideal) being logged (OutputDebugString or syslog) where one can readily find it. Errors rare enough that we get time to forget between them. Pharo needs to help us a bit more - afteall, it works for us, right? >> >> >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] >> Sent: Tuesday, January 31, 2012 3:30 AM >> To: Pharo-project(a)lists.gforge.inria.fr Development >> Subject: [Pharo-project] CogVM driver vs executable >> >> In response to my posting >> >> http://lists.gforge.inria.fr/pipermail/pharo-project/2012-January/058790.ht… >> >> I got feedback from people trying to use SSL with Eliot's CogVM >> >> http://www.mirandabanda.org/files/Cog/VM/VM.r2522/coglinux.tgz >> >> instead of the Pharo one that I normally use >> >> http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip >> >> They reported that it did not work for them. >> >> So I tried this myself on my Ubuntu 11.10 (GNU/Linux 3.0.0-14-virtual i686) server and yes it fails with 'can't infer base LD_LIBRARY_PATH. Aborting.' which was discussed in this list before. I am not qualified to really understand those discussions. >> >> But when I used the executable 'inside' coglinux/lib/squeak/4.0-2522/squeak everything worked as expected. >> >> So the question is what does the driver (I don't know if that is the right word) coglinux/squeak or coglinux/bin/squeak do ? >> Since the pharo variant seems to operate fine without it, do we need the driver ? >> >> Sven >> > > -- Best regards, Igor Stasenko.

Jan. 31, 2012

Re: [Pharo-project] Cog+linux: external module not found

by Igor Stasenko

On 31 January 2012 09:36, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > GÃ¶ran, > > Thanks for what you do, and for noticing what I (at least try) to contribute. Â Some other "tangible" items in my queue *will* be worth the wait[*]. Â I sincerely hope you are correct about a misunderstanding being at the base of thread. > > Hopefully, we can all dust ourselves off [**] and make FFI robust everywhere. > > Best regards, > > Bill > > [*] Â I know I've said this for essentially Pharo's entire life cycle, but it's true... Â Callbacks, my kingdom for callbacks. > you're waiting for too long. why you cannot just make it happen by yourself? or do you think that i/others will oppose to that "don't even think to go onto my territory!!" ? :) i mean, if you need them so badly, why you sitting and waiting, instead of making it happen? I would really appreciate any help with improving NativeBoost, because i have too many things to be done, and simply lacking time for doing everything at once. > [**] Â Some US slang for Stef's benefit :) > > > ________________________________________ -- Best regards, Igor Stasenko.

Jan. 31, 2012

Re: [Pharo-project] CogVM driver vs executable

by Schwab,Wilhelm K

Sven, Your problem *sounded* reminiscent of one I recently cracked. I agree that the loading is over complicated, but at least some of that is due to VERY valid security features in Ubuntu. Apologies if I missed the mark. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Tuesday, January 31, 2012 10:10 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] CogVM driver vs executable Thx for the reply, but as I said, I don't understand this library loading, or why it has to be so complicated. I am all for putting the maximum possible amount of control in the image. In the mean time I saw that the driver is actually just a shell script ;-) (I knew that but I guess I forgot). My main question remains: why is this necessary since it works without the scipt just as well. Sven On 31 Jan 2012, at 11:00, Schwab,Wilhelm K wrote: > Sven, > > I'm not sure what to tell you. The "can't infer" message you are experiencing ***might*** be the one time the vm is actually telling what's wrong. If so, it's PROGRESS. Doesn't feel like that in your shoes, I know.... > > The bane of my existence is a silent failure (I dread those two word in that sequence...) of the vm to look in the right place. What did Nick suggest to me? strace, I think (it's in the archives). You might run under it to see if you can gain some insight; the tool in question does not pt > > DON'T LET THIS HAPPEN TO YOU<g>: the tool in question[*] logs its output to sterr(?), not stdout as one might expect. If you try it, use the -o option (I think) to direct to a file, then cat and grep are your friends. I remember "streaming" this into the archives, but I can't see them to check the facts. > > I solved my problem by noting where the vm was actually looking and making sym links to trick it (should not have to...) into working (very good). Let's all send kind thoughts to Sig - maybe he'll pull the search policy into the image, where it belongs. We will still want vm level logging (syslog etc.) in case the image can't run. > > SECURITY: Ubuntu gets it right (took me a while to realize same) by "forcing" us to use dlconfig to map names to libraries. I don't really understand it all, but I might be able to fake some useful answers if that is confusing. You might need to use dlconfig to "fix" Ubuntu, and then links to fool the vm into looking where it should. > > HTH, > > Bill > > > [*] short term memory disorder<g>, which is precisely why we want informative errors reaching the Smalltalk code (and?)/OR(ideal) being logged (OutputDebugString or syslog) where one can readily find it. Errors rare enough that we get time to forget between them. Pharo needs to help us a bit more - afteall, it works for us, right? > > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] > Sent: Tuesday, January 31, 2012 3:30 AM > To: Pharo-project(a)lists.gforge.inria.fr Development > Subject: [Pharo-project] CogVM driver vs executable > > In response to my posting > > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-January/058790.ht… > > I got feedback from people trying to use SSL with Eliot's CogVM > > http://www.mirandabanda.org/files/Cog/VM/VM.r2522/coglinux.tgz > > instead of the Pharo one that I normally use > > http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip > > They reported that it did not work for them. > > So I tried this myself on my Ubuntu 11.10 (GNU/Linux 3.0.0-14-virtual i686) server and yes it fails with 'can't infer base LD_LIBRARY_PATH. Aborting.' which was discussed in this list before. I am not qualified to really understand those discussions. > > But when I used the executable 'inside' coglinux/lib/squeak/4.0-2522/squeak everything worked as expected. > > So the question is what does the driver (I don't know if that is the right word) coglinux/squeak or coglinux/bin/squeak do ? > Since the pharo variant seems to operate fine without it, do we need the driver ? > > Sven >

Jan. 31, 2012

Re: [Pharo-project] CogVM driver vs executable

by Igor Stasenko

On 31 January 2012 16:10, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Thx for the reply, but as I said, I don't understand this library loading, or why it has to be so complicated. > me neither.. so i don't even care to read this topic carefully. i can't understand why we need such complex library lookup logic in VM ,and other "driver" mechanisms. i already proposed to move all this logic to image side, so at least we could have a direct control of what happening, as well as a good error handling in case of troubles. while at VM, there should be a simplest possible thing to stay, a function which takes a path to library and reports a handle to it if it loaded it or error code, why it cannot be loaded (file not found, lib file found but cannot be initialized etc). > I am all for putting the maximum possible amount of control in the image. > > In the mean time I saw that the driver is actually just a shell script ;-) (I knew that but I guess I forgot). > > My main question remains: why is this necessary since it works without the scipt just as well. > > Sven > > On 31 Jan 2012, at 11:00, Schwab,Wilhelm K wrote: > >> Sven, >> >> I'm not sure what to tell you. Â The "can't infer" message you are experiencing ***might*** be the one time the vm is actually telling what's wrong. Â If so, it's PROGRESS. Â Doesn't feel like that in your shoes, I know.... >> >> The bane of my existence is a silent failure (I dread those two word in that sequence...) of the vm to look in the right place. Â What did Nick suggest to me? Â strace, I think (it's in the archives). Â You might run under it to see if you can gain some insight; the tool in question does not pt >> >> DON'T LET THIS HAPPEN TO YOU<g>: the tool in question[*] logs its output to sterr(?), not stdout as one might expect. Â If you try it, use the -o option (I think) to direct to a file, then cat and grep are your friends. Â I remember "streaming" this into the archives, but I can't see them to check the facts. >> >> I solved my problem by noting where the vm was actually looking and making sym links to trick it (should not have to...) into working (very good). Â Let's all send kind thoughts to Sig - maybe he'll pull the search policy into the image, where it belongs. Â We will still want vm level logging (syslog etc.) in case the image can't run. >> >> SECURITY: Ubuntu gets it right (took me a while to realize same) by "forcing" us to use dlconfig to map names to libraries. Â I don't really understand it all, but I might be able to fake some useful answers if that is confusing. Â You might need to use dlconfig to "fix" Ubuntu, and then links to fool the vm into looking where it should. >> >> HTH, >> >> Bill >> >> >> [*] short term memory disorder<g>, which is precisely why we want informative errors reaching the Smalltalk code (and?)/OR(ideal) being logged (OutputDebugString or syslog) where one can readily find it. Â Errors rare enough that we get time to forget between them. Â Pharo needs to help us a bit more - afteall, it works for us, right? >> >> >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] >> Sent: Tuesday, January 31, 2012 3:30 AM >> To: Pharo-project(a)lists.gforge.inria.fr Development >> Subject: [Pharo-project] CogVM driver vs executable >> >> In response to my posting >> >> Â http://lists.gforge.inria.fr/pipermail/pharo-project/2012-January/058790.ht… >> >> I got feedback from people trying to use SSL with Eliot's CogVM >> >> Â http://www.mirandabanda.org/files/Cog/VM/VM.r2522/coglinux.tgz >> >> instead of the Pharo one that I normally use >> >> Â http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip >> >> They reported that it did not work for them. >> >> So I tried this myself on my Ubuntu 11.10 (GNU/Linux 3.0.0-14-virtual i686) server and yes it fails with 'can't infer base LD_LIBRARY_PATH. Aborting.' which was discussed in this list before. I am not qualified to really understand those discussions. >> >> But when I used the executable 'inside' coglinux/lib/squeak/4.0-2522/squeak everything worked as expected. >> >> So the question is what does the driver (I don't know if that is the right word) coglinux/squeak or coglinux/bin/squeak do ? >> Since the pharo variant seems to operate fine without it, do we need the driver ? >> >> Sven >> > > -- Best regards, Igor Stasenko.

Jan. 31, 2012

Re: [Pharo-project] Enthousiasm is the main currency among developers

by Marcus Denker

On Jan 31, 2012, at 12:10 PM, Frank Shearar wrote: > On 31 January 2012 14:44, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: >> I agree whole heartedly after a month of Pharo being used as a tool for >> newbies. >> >> a) Crashes... Make sure to run an up-to-date vm and image (and yes, the downloads are not up to date...) And it's important that people report problems. If problems are not reported, it is as if they would not exist. >> b) Bugs in basic functionality: Morphic as well as in other places Morphic is just crap. But what can we do else than slowly fixing what we see? >> c) The User Guide is not in synch with the current stable Pharo.. in simple >> images of browsers.. We just can't update pharo by example for every release... the day has just 24 hours. But it is true that the version right now is far too old. (based on a horibly slow 1.0 with a completely different browser...) In general there are two options: -> give up and do something else -> fix the problems, step by step. -- Marcus Denker -- http://marcusdenker.de

Jan. 31, 2012

Re: [Pharo-project] CogVM driver vs executable

by Sven Van Caekenberghe

Thx for the reply, but as I said, I don't understand this library loading, or why it has to be so complicated. I am all for putting the maximum possible amount of control in the image. In the mean time I saw that the driver is actually just a shell script ;-) (I knew that but I guess I forgot). My main question remains: why is this necessary since it works without the scipt just as well. Sven On 31 Jan 2012, at 11:00, Schwab,Wilhelm K wrote: > Sven, > > I'm not sure what to tell you. The "can't infer" message you are experiencing ***might*** be the one time the vm is actually telling what's wrong. If so, it's PROGRESS. Doesn't feel like that in your shoes, I know.... > > The bane of my existence is a silent failure (I dread those two word in that sequence...) of the vm to look in the right place. What did Nick suggest to me? strace, I think (it's in the archives). You might run under it to see if you can gain some insight; the tool in question does not pt > > DON'T LET THIS HAPPEN TO YOU<g>: the tool in question[*] logs its output to sterr(?), not stdout as one might expect. If you try it, use the -o option (I think) to direct to a file, then cat and grep are your friends. I remember "streaming" this into the archives, but I can't see them to check the facts. > > I solved my problem by noting where the vm was actually looking and making sym links to trick it (should not have to...) into working (very good). Let's all send kind thoughts to Sig - maybe he'll pull the search policy into the image, where it belongs. We will still want vm level logging (syslog etc.) in case the image can't run. > > SECURITY: Ubuntu gets it right (took me a while to realize same) by "forcing" us to use dlconfig to map names to libraries. I don't really understand it all, but I might be able to fake some useful answers if that is confusing. You might need to use dlconfig to "fix" Ubuntu, and then links to fool the vm into looking where it should. > > HTH, > > Bill > > > [*] short term memory disorder<g>, which is precisely why we want informative errors reaching the Smalltalk code (and?)/OR(ideal) being logged (OutputDebugString or syslog) where one can readily find it. Errors rare enough that we get time to forget between them. Pharo needs to help us a bit more - afteall, it works for us, right? > > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] > Sent: Tuesday, January 31, 2012 3:30 AM > To: Pharo-project(a)lists.gforge.inria.fr Development > Subject: [Pharo-project] CogVM driver vs executable > > In response to my posting > > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-January/058790.ht… > > I got feedback from people trying to use SSL with Eliot's CogVM > > http://www.mirandabanda.org/files/Cog/VM/VM.r2522/coglinux.tgz > > instead of the Pharo one that I normally use > > http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip > > They reported that it did not work for them. > > So I tried this myself on my Ubuntu 11.10 (GNU/Linux 3.0.0-14-virtual i686) server and yes it fails with 'can't infer base LD_LIBRARY_PATH. Aborting.' which was discussed in this list before. I am not qualified to really understand those discussions. > > But when I used the executable 'inside' coglinux/lib/squeak/4.0-2522/squeak everything worked as expected. > > So the question is what does the driver (I don't know if that is the right word) coglinux/squeak or coglinux/bin/squeak do ? > Since the pharo variant seems to operate fine without it, do we need the driver ? > > Sven >

Jan. 31, 2012

Re: [Pharo-project] Enthousiasm is the main currency among developers

by Frank Shearar

On 31 January 2012 14:44, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > I agree whole heartedly after a month of Pharo being used as a tool for > newbies. > > a) Crashes... > b) Bugs in basic functionality: Morphic as well as in other places > c) The User Guide is not in synch with the current stable Pharo.. in simple > images of browsers.. > > Very very basic/ simple stuff.. but I realized more sharply that not all are > equal in comprehension and guess or accept these to dig their heel in > further and experience the joy inside.. they just balk and wonder if Pharo > is even half as good as VW/ VA.. where I believe it is just pure uncut > diamond inside.. unpolished.. but work is going on from the craftsmen.. > every day.. to get there.. Maybe so... but if you're using Pharo 1.4 you should be aware that you're working at the "coal face", on something that's under active development. If you want something stable, use a stable version. frank > But I vote for the basic principle, work hard to get the very basic kernel, > a stable system that is guaranteed not to crash and work absolutely > predictably.. not throw in stuff which half works even like the debugger > stuff currently, which to a beginner is quite confusing when steps out of > line. > > > On Sat, Jan 28, 2012 at 3:19 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: >> >> >> >> On Fri, Jan 27, 2012 at 11:51 AM, Guido Stepken <gstepken(a)googlemail.com> >> wrote: >>> >>> Hi Elliot! >>> >>> When I rethink, why new programming languages came up from zero to a >>> significant market share, like PERL, PHP, Python, Ruby, JAVA, C# (.net) >>> Visual Basic, Visual C++ and others died out, like Delphi, >>> TurboBasic/Pascal/C I could name different reasons: >>> >>> - Free license vs. expensive >>> - Wrong payment model (per developer, per runtime, both) >>> - Good, free support on websites vs. "Bronze/silver/gold" >>> paystupid-support >>> - Attractiveness of one "killer app" that made programmers change to >>> another language >>> - Portability of code onto other platforms >>> - Mightyness of libraries >>> - Missing standards, protocols, support of hardware >>> - Good vs. bad marketing, deciders not convinced that product will >>> survive/missing timeline, visions, lack of money in background >>> - Subcritical mass of programmers using product, lack of professionals >>> >>> That was in former times. >>> >>> Today, new criterias play a far more relevant role, hat haven't really >>> existed just 3 years ago: >>> >>> - Has it (the OS,the programming language and GUI framework) an >>> appstore/plugin concept to let free, creative brains being able to >>> participate, earn money with? >>> - Barrier - free payment model included (mobile payment, card, bank >>> account)? >>> - Free use with sponsoring by ads possible (programmers payed from >>> multiple resources, not user alone) >>> - Cryptographic prevention of missuse included? >>> - Free and matured SDK available? >>> - Connections to social software like facebook/twitter/Google+/Groupon >>> included (API access, programming language and all protocols supported) >>> - GUI designed for desktop as well usable for touch and self adapting to >>> different screen/touch sizes? >>> - Touch gestures possible and lib avail? >>> - Microsofts Kinect hardware/video recognition of faces, hand/face mimic >>> gestures possible and supported in libs? >>> - Voice recognition supported? >>> - Mobile ready? (touch, GPS, compass, barometer, gyro, hardware OpenGL) >>> - Rockstable? >>> - Fast, running in low power devices? Joule per clock cycle ratio??? >>> - Critical mass of users already reached, increasing? >>> - Critical number of apps there to raise interest? >>> ... >>> >>> So, the Pharo developers might now decide, what to invest their >>> brainpower into! :-) >>> >>> Just my 2ct. >> >> >> OK, that looks like a great list. Â But don't you agree that criticism (in >> the sense of something that leads to quality software engineering) underlies >> several of these, such as Rockstable, Fast, running on low-power devices, >> etc? Â To me, being critical doesn't mean being uncreative or conservative; >> it means thinking about what you're doing, and doing a good job. >>> >>> Guido Stepken >>> >>> Am 27.01.2012 19:46 schrieb "Eliot Miranda" <eliot.miranda(a)gmail.com>: >>> >>>> >>>> >>>> On Fri, Jan 27, 2012 at 5:33 AM, Marcus Denker <marcus.denker(a)inria.fr> >>>> wrote: >>>>> >>>>> >>>>> On Jan 27, 2012, at 6:13 AM, dimitris chloupis wrote: >>>>> >>>>> > This article is really encapsulates the attitude and what is wrong >>>>> > with programming in general. The attitude of superiority and intelligence >>>>> > that seems to plague coders and being the biggest obstacle to progress. >>>>> >>>>> Yes! The "Everyone is dumb but me" phenomenon... >>>>> >>>>> What those "intelligent" people don't get is that complexity is >>>>> inherently exponential. So even if you are >>>>> 10 times more intelligent than me (very well possible), it is >>>>> *completely* irrelevant considering that complexity >>>>> grows non-linearly. >>>>> >>>>> If you combine this with the notion of Evolution: that it is impossible >>>>> to creat "the perfect" out of nothing, yet >>>>> entropy grows when you incrementally improve things... than this has >>>>> some very serious consequences. >>>>> >>>>> > For me the main problem with is the whole aura of Â "elitism" , what >>>>> > better example than Lisp, where beginners are attacked and be excluded. >>>>> >>>>> We had the same effect in Squeak at the end. No progress, every >>>>> improvement was actively fighted against, if needed with the nice argument >>>>> that >>>>> one can do it even better, and only "the best" is worth for Squeak. >>>>> >>>>> Another thing that "intelligent" people don't get is that critizising >>>>> is trivial: You can *always* do better, there is no perfection. It's an >>>>> endless process. >>>>> This implies that one has to accept and embrace imperfection if one >>>>> wants to have a future. Else you end up never finishing anything, the death >>>>> of any >>>>> incremental progress. >>>> >>>> >>>> But criticism is essential. Â How does one identify a mistake if not by >>>> criticising? Â There's a huge difference between constructive criticism >>>> (analysis, testing, comparison, evaluation, measurement) and negativity >>>> (denial, fear, slander). Â How can one engineer without measurement, without >>>> thought? Â Being agile doesn't imply being random. Â Evolution measures, and >>>> most harshly; the weaker don't survive. >>>> >>>>> >>>>> Pharo was started with the explicit goal to do as many mistakes as >>>>> possible, as fast as possible. >>>>> >>>>> Â Â Â Â Marcus >>>>> >>>>> -- >>>>> Marcus Denker -- http://marcusdenker.de >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>>> >> >> >> >> -- >> best, >> Eliot >> >

Jan. 31, 2012

Re: [Pharo-project] Which COG VM?

by Marcus Denker

On Jan 22, 2012, at 10:50 AM, Johan Brichau wrote: > > I think somebody that maintains the website needs to replace the VM that is linked on the download page with the latest VM built in Jenkins. > > I had the same issues but when I switched to the latest built on Jenkins, I had no issues anymore. > We need to once and for all finish to have a *complete* continous integration setup... we really should push towards that, else the on-click will be always out of date. Now there are lots of tiny trivial unimportant steps to go there that somehow never get done... I have put this on my TODO list, but it will take a while, sadly. Marcus -- Marcus Denker -- http://marcusdenker.de

Jan. 31, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Otto Behrens

Hi, > You mean having the class definition in a blob of its own? > From what I see, that's already kinda what you're doing, except you > have the class comment in there as wellâ¦ Yes, essentially we have that. Would like to clean it up by only having what's necessary in there. I was wondering more if it is possible to do without having a file system checkout of the class definition. In other words, if the class definition in the image could serve as the working copy of the object in the git repository. I must read more on what the other guys did with the git interfaces (such as gitfs and gitosis) to understand what it comes down to. If this is possible, it would make merging, loading and committing essentially one step. The disadvantage could be a tight coupling with git. Otto

Jan. 31, 2012