- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Spoon presentation 2012-02-24

by Schwab,Wilhelm K

Dollars in the hundreds are hardly a deterrent to business, nor enough to make developers here jump through hoops that involve huge amounts of work. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Guido Stepken [gstepken(a)googlemail.com] Sent: Thursday, March 01, 2012 6:20 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Spoon presentation 2012-02-24 > You're not in supermarket. You are on pharo-development list. Exactly. Perhaps a auction might help, where Pharo users meet programmers. A "feature wanted" as offer, Smalltalk programmers may secretly offer "their implementation" for â¬$ (2nd lowest offer wins, see 'swiss auction') and as soon the money is collected (open sponsor bid), the programmer is contracted to implement. Pharo group just helps implementing a bit, being as well payed, different models may apply. I have no problem to pay for features that i want to have implemented, but i simply refuse to sponsor Pharo development, not knowing what for and when it will be ready. With open bids for development (anonymous bids for implementation) it will be fun for companies to continuously raise their offer to see a feature implemented soon. The more important it is for their business, the more and the quicker they spend. AND - its cheap, cause cost divide up among investors. There are lots of companies waiting, who - rather sooner as later - would leave commercial platforms costing them several hundred bucks a year per client. But as long as the Pharo group does not offer them a instrument to steer and control Pharo development, nothing will happen. Develop the development process! regards, Guido Stepken

March 1, 2012

Re: [Pharo-project] fun with NBOpenGL

by Igor Stasenko

So, Erwan if you need to handle keyboard in your own project, just take JB's code and here you go :) -- Best regards, Igor Stasenko.

March 1, 2012

Re: [Pharo-project] Spoon presentation 2012-02-24

by Guido Stepken

> You're not in supermarket. You are on pharo-development list. Exactly. Perhaps a auction might help, where Pharo users meet programmers. A "feature wanted" as offer, Smalltalk programmers may secretly offer "their implementation" for â¬$ (2nd lowest offer wins, see 'swiss auction') and as soon the money is collected (open sponsor bid), the programmer is contracted to implement. Pharo group just helps implementing a bit, being as well payed, different models may apply. I have no problem to pay for features that i want to have implemented, but i simply refuse to sponsor Pharo development, not knowing what for and when it will be ready. With open bids for development (anonymous bids for implementation) it will be fun for companies to continuously raise their offer to see a feature implemented soon. The more important it is for their business, the more and the quicker they spend. AND - its cheap, cause cost divide up among investors. There are lots of companies waiting, who - rather sooner as later - would leave commercial platforms costing them several hundred bucks a year per client. But as long as the Pharo group does not offer them a instrument to steer and control Pharo development, nothing will happen. Develop the development process! regards, Guido Stepken

March 1, 2012

Re: [Pharo-project] leaking semaphores

by Henrik Johansen

On Mar 1, 2012, at 11:41 AM, Guido Stepken wrote: > > You might still laugh at me... i don't. > > Not at you, just your way of trying to provoke a response. "Someone mentioned semaphores! Better link this article and tell them how it should be done!" without even checking if it's ontopic to the actual discussion. If you did, you'd find the use of semaphores in this case actually being close to what the paper describes as a compromise between mutex and spin lock used for interrupt processing. "What, he didn't bite, FIRE ALL CANNONS WITH EVERYTHING I THINK IS WRONG" Yeah, as if that makes it more likely I'd be interested in derailing the conversation further. (Other than with snide replies like this) TLDR; Bug diagnosed/fix proposed, thanks to Milan for a good reproducible test case. Could someone contact Lukas and see if he can update the package? Cheers, Henry

March 1, 2012

Re: [Pharo-project] leaking semaphores

by Igor Stasenko

On 1 March 2012 11:41, Guido Stepken <gstepken(a)googlemail.com> wrote: > No. I just tried to teach Pharo to do several things in parallel: Seaching > stings in several 1 GB files, opening and reading several databases at once > in parallel, handing results over sockets to several clients. Try it > yourself. > Whatever you do with Pharo, you won't get any smooth IO, even if you use > COGMT. Smalltalk code is not yet adapted, it seems. Same with eventhandlers. > Try editing while copying and filtering a file in background. Happy waiting! > > I had much success with Smalltalk MT, LUAJit, medium success with node.js > ... > > Don't get me wrong, but business develops to realtime filtering of > concurrent information streams coming from different sources (twitter, > facebook, mail, irc, p2p, databases, homepages, rss, XML, Soap ) and that > intelligently presented in realtime on my Desktop. > > We did intensive testing of several interpreters. > > I personally really prefer Pharo, because it offers a outstanding, very > complex construction kit for doing marvellous things, beginning from > "abstract connectors" that combine filters with editors with gui, web, > streams, databases, over to very good IDE up to certain (decreasing) > compatibility to squeak and its mass of "toy apps". > > I think, that, when a deeper understanding of how to acheive parallelism, > realtime, concurrency comes to Smalltalk programmers (not just starting > coroutines and hoping, the kernel gets it right, claiming everything is > multithreaded), Pharo very soon could be business ready! :-) > > And it is good to understand, *why* Wikipedia now uses LUAJit (a highly > dynamic language, like Smalltalk), Blizzard (World of Warcraft), Steam > (realtime control of complex game worlds) use LUAJit, EVE uses Stackless > Python with continuations. Smalltalk would be very well suited, but its > implementations are missing important features, realtime qualities, real > concurrency, not just one at the surface, claiming apps being > "multithreaded". > > Seaside, e.g. immediately drops to under 1/second, at even 10 simulaneous > clients, when data comes from SQL or even OODB, means case of cache misses. > Pharo becomes unresponsive. > > For me, good architectures can be recognized, when they smoothly go on > serving, even at 50 times overload, still keeping small memory footprint. > Compare to Linux at high loads (sshd, telnetd not answering) and FreeBSD > (you can still login, even if 50.000 clients connected). > > You might still laugh at me... i don't. > Finally something worth replying. Back in 2007 i did a HydraVM, which were capable of running multiple interpreters in parallel on separate native threads. It was a proof-of-concept. Showing that things are doable. What is hard to do is to make everything in image side to be instantly aware of new feature and make use of it. You need to develop tools around it, like inter-image communication, remote debugging, and last but not least figuring out how you can spawn a dozens of micro-images which are not full-blown multimegabyte image as we usually having, but contain only some small algorithm, which will be running on given thread. There's also a RoarVM, which attacking the same problem but at slightly different angle than HydraVM. So, indeed, there's nothing to laugh at. The sad thing is that you have to rewrite a lot in kernel to use new architecture in vm, and there's no way back: no way how it can be backwards compatible. In case if you insist of backward compatibility, the adoption will never be as good as design based on new concepts. It also requires a lot of study, in multiple areas as well as evaluating different approaches. Another sad thing is that you just trolling, thinking that only you know how to do things right and treating people here either blind or stupid idiots. > Have fun, Guido Stepken > > Am 01.03.2012 10:29 schrieb "Henrik Johansen" > <henrik.s.johansen(a)veloxit.no>: > >> >> On Mar 1, 2012, at 10:03 AM, Guido Stepken wrote: >> >> As long as GC, recompile, (see blocked UI during updates), ffi database >> drivers completely block Smalltalk execution or do not access external >> databases smoothly in parallel (also see async I/O, MP) i see only one laugh >> here - that's indeed you! >> >> Have fun! >> >> Guido Stepken >> >> >> >> Aaah, the good ol' "If you can't hit with a rifle, switch to a shotgun" >> approach, haven't seen that in a while. >> >> Have fun! >> Henry -- Best regards, Igor Stasenko.

March 1, 2012

Re: [Pharo-project] leaking semaphores

by Guido Stepken

No. I just tried to teach Pharo to do several things in parallel: Seaching stings in several 1 GB files, opening and reading several databases at once in parallel, handing results over sockets to several clients. Try it yourself. Whatever you do with Pharo, you won't get any smooth IO, even if you use COGMT. Smalltalk code is not yet adapted, it seems. Same with eventhandlers. Try editing while copying and filtering a file in background. Happy waiting! I had much success with Smalltalk MT, LUAJit, medium success with node.js ... Don't get me wrong, but business develops to realtime filtering of concurrent information streams coming from different sources (twitter, facebook, mail, irc, p2p, databases, homepages, rss, XML, Soap ) and that intelligently presented in realtime on my Desktop. We did intensive testing of several interpreters. I personally really prefer Pharo, because it offers a outstanding, very complex construction kit for doing marvellous things, beginning from "abstract connectors" that combine filters with editors with gui, web, streams, databases, over to very good IDE up to certain (decreasing) compatibility to squeak and its mass of "toy apps". I think, that, when a deeper understanding of how to acheive parallelism, realtime, concurrency comes to Smalltalk programmers (not just starting coroutines and hoping, the kernel gets it right, claiming everything is multithreaded), Pharo very soon could be business ready! :-) And it is good to understand, *why* Wikipedia now uses LUAJit (a highly dynamic language, like Smalltalk), Blizzard (World of Warcraft), Steam (realtime control of complex game worlds) use LUAJit, EVE uses Stackless Python with continuations. Smalltalk would be very well suited, but its implementations are missing important features, realtime qualities, real concurrency, not just one at the surface, claiming apps being "multithreaded". Seaside, e.g. immediately drops to under 1/second, at even 10 simulaneous clients, when data comes from SQL or even OODB, means case of cache misses. Pharo becomes unresponsive. For me, good architectures can be recognized, when they smoothly go on serving, even at 50 times overload, still keeping small memory footprint. Compare to Linux at high loads (sshd, telnetd not answering) and FreeBSD (you can still login, even if 50.000 clients connected). You might still laugh at me... i don't. Have fun, Guido Stepken Am 01.03.2012 10:29 schrieb "Henrik Johansen" <henrik.s.johansen(a)veloxit.no >: > > On Mar 1, 2012, at 10:03 AM, Guido Stepken wrote: > > As long as GC, recompile, (see blocked UI during updates), ffi database > drivers completely block Smalltalk execution or do not access external > databases smoothly in parallel (also see async I/O, MP) i see only one > laugh here - that's indeed you! > > Have fun! > > Guido Stepken > > > Aaah, the good ol' "If you can't hit with a rifle, switch to a shotgun" > approach, haven't seen that in a while. > > Have fun! > Henry >

March 1, 2012

Re: [Pharo-project] Spoon presentation 2012-02-24

by Igor Stasenko

On 1 March 2012 10:48, Carlo <snoobabk(a)yahoo.ie> wrote: > Hi Craig > > Guido's email was meant to read:Â Thanks for sharing your work! > Yes. > > On 01 Mar 2012, at 9:29 AM, Guido Stepken wrote: > > People like 1-klick Images ... Setup.exe ... No raw ZIP file, no additional > installation of unzip, no shell, no "cd" no ".bat" > > If you want to really make people try software, make it as comfortable, as > possible for them. Even the 1-klick-Image of Pharo is no such one, its a 7 > or 8 mousklick Image. When it is advertised as 1-klick, i expect that to be > "one klick" if it is advertized "stable" i expect that to be stable, > rockstable! Damn! "No half way things!". Lasy attitude by the programmer > directly shows up in the install routine. > You're not in supermarket. You are on pharo-development list. Here the half-way is norm. And "stable" and "complete" happens once per year , when new version released, but in fact those terms are not applicable as well. If you would know what "continuous development" is, you would never put "half way", because every release you get will be characterized as a "half way", because it is only a milestone we put, after a lot of things done, but there's always more to be done. We're not cooking cakes here. We're not selling TV-sets here. > When i see such a lousy packed piece of software i just expect crap quality > in it, sorry! > > Take EToys Setup.exe, replace the image, re-sfx again. Is it so hard??? Same > with Pharo. > > Tnx 4 understanding, Guido Stepken > > Am 01.03.2012 05:42 schrieb "Craig Latta" <craig(a)netjam.org>: >> >> >> > No, meant: http://dl.dropbox.com/u/15188004/spoon >> > /Spoon%203%20alpha%203.zip >> >> Â Â That's a standard "all-in-one" Squeak release, the bits for all >> platforms are there. >> >> >> -C >> >> -- >> Craig Latta >> www.netjam.org/resume >> +31 6 2757 7177 >> + 1 415 287 3547 >> >> >> > -- Best regards, Igor Stasenko.

March 1, 2012

Re: [Pharo-project] FilePlugin rant

by Camillo Bruni

Hi Sven, I did a quick test with Igor by removing all unnecessary code in FileDirectory >> #directoryContentsFor:do: and you will see that just running #primLookupEntryIn:index: will take 100% of the time. best cami On 2012-03-01, at 11:14, Sven Van Caekenberghe wrote: > Camillo, > > On 01 Mar 2012, at 10:54, Camillo Bruni wrote: > >> I recently started to hack around Monticello due to very low response times when having a huge package cache. >> >> Now interestingly the FilePlugin primitives for listing files are horrible! >> >> Example: >> ----------------------------------------------------------- >> MC often requests a list of all mzc's cached locally: >> (FileDirectory default / 'package-cache') entries >> >> In my case there are 4300 mczs in the shared package-cache >> timeToRun yields a nightmarish 2050ms for this, >> further investigation leads to the fact that most of the time is spent in the file primitive! >> >> Now thats some 2ms for a single directory entry! >> [Just as a side note, ruby1.8 does the same job in 10ms :D] >> ----------------------------------------------------------- >> >> primLookupEntryIn: fullPath index: index >> <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin'> >> >> ----------------------------------------------------------- >> >> I think we should definitely add another primitive which directly lists >> the file under a certain path. >> >> Of course this will break compatibility with existing code, but >> I think the current approach does not scale... >> >> best >> cami > > I have > > (FileDirectory default / 'package-cache') entries size 5053 > [ (FileDirectory default / 'package-cache') entries ] timeToRun 2012 > > But if I run it in the Time Profiler, I get this: > > <Screen Shot 2012-03-01 at 11.12.46.png> > > How do you manage to track the primitive ? > > Why/how would an extra primitive or better implementation of #entries break compatibility ? > > Sven > >

March 1, 2012

Re: [Pharo-project] fun with NBOpenGL

by Jean Baptiste Arnaud

Maybe don't feed the troll ... One day, the Grinch's small heart will grown of three sizes. On Mar 1, 2012, at 10:28 AM, Igor Stasenko wrote: > On 1 March 2012 08:54, Guido Stepken <gstepken(a)googlemail.com> wrote: >> At minimum as Pharo demo i expect to see data coming from a mysql database >> or csv file, flying around as bar graph on the pharo desktop. >> >> Such simple things i had in 1986 as demo in Turbo Pascal. See FreePascal, >> e.g. Any platform, stable compiler, plenty of libs, blazingly fast, good >> community support. >> > Good. Now since you repeating same rhetoric, don't expect that you > will get different reaction from me: > - if everything is so perfect somewhere else but not here, my only > question is: > why you still here? and what you trying to prove? that there's > always something better which can be found elsewhere? > you don't have to prove it, i know it by myself already. But that's > why i'm here. > >> Have fun, Guido Stepken >> >> Am 01.03.2012 03:06 schrieb "Igor Stasenko" <siguctua(a)gmail.com>: >> >>> On 1 March 2012 04:01, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 1 March 2012 03:00, Guido Stepken <gstepken(a)googlemail.com> wrote: >>>>> My first rotating cube i programmed in 1982, when i was 16. Today, >>>>> Professors at Inria learn it to do from scratch. O tempora, o mores! >>>>> >>>>> What advance in informatics!!! >>> >>> btw, you can train your speech on streets. >>> Every time you will see a baby trying to stand and walk, you can say: >>> O tempora, o mores! I was able to do that <your age> - 1 years back! >>> >>>>> >>>>> B.t.w: Turbo Pascal 8086 Compiler, Editor was programmed within 3 weeks >>>>> by >>>>> Heilsberg, under control of a notary!!! >>>>> >>>>> Today, it takes 3 years with 5 people to get a simple Smalltalk >>>>> compiler >>>>> right. >>>>> >>>> you make no sense. >>>> But i glad that you like it :) >>>> >>>>> Have fun! >>>>> >>>>> Guido Stepken >>>>> >>>>> I really like do useless thing ;-p. >>>>> >>>>> The control >>>>> for the cube >>>>> x : increase by one the number of cube on the x axis >>>>> y : increase by one the number of cube on the y axis >>>>> z : increase by one the number of cube on the z axis >>>>> X : decrease by one the number of cube on the x axis >>>>> Y : decrease by one the number of cube on the y axis >>>>> Z : decrease by one the number of cube on the z axis >>>>> >>>>> left arrow : turn left >>>>> right arrow : turn right >>>>> up arrow : turn up >>>>> down arrow : turn down >>>>> >>>>> Shift left arrow : translate left >>>>> Shift right arrow : translate right >>>>> Shift up arrow : translate up >>>>> Shift down arrow : translate down >>>>> >>>>> space move forward. >>>>> ctrl space (because dont take shift space as specific keystroke and >>>>> array >>>>> dont take ctrl so i choose that): move backward. >>>>> >>>>> i search during half a hour but dont find a relevant quote from pinky >>>>> and >>>>> the brain. sad. >>>>> What i really like Igor is, i don't need to close the morph for apply >>>>> my >>>>> change to the render method, i mean in addition to not recompile the >>>>> whole >>>>> project. >>>>> >>>>> >>>>> <NBOpenGL-JB end i am tired.st> >>>>> >>>>> >>>>> >>>>> <Screen shot 2012-03-01 at 1.26.09 AM.png> >>>>> >>>>> >>>>> On Feb 29, 2012, at 11:38 PM, Igor Stasenko wrote: >>>>> >>>>> woow... >>>>> >>>>> it is always fun to see that something which looks like trash (who can >>>>> be impressed by a stupid rotating cube today?) >>>>> can be turned into piece of art with a few keystrokes, just by taking >>>>> right pictures :) >>>>> >>>>> And that's why it is soo fun to work with graphics. >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>>> Regards >>>>> Jean Baptiste Arnaud >>>>> jbaptiste.arnaud(a)gmail.com >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > > > -- > Best regards, > Igor Stasenko. > Regard Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

March 1, 2012

Re: [Pharo-project] FilePlugin rant

by Sven Van Caekenberghe

Camillo, On 01 Mar 2012, at 10:54, Camillo Bruni wrote: > I recently started to hack around Monticello due to very low response times when having a huge package cache. > > Now interestingly the FilePlugin primitives for listing files are horrible! > > Example: > ----------------------------------------------------------- > MC often requests a list of all mzc's cached locally: > (FileDirectory default / 'package-cache') entries > > In my case there are 4300 mczs in the shared package-cache > timeToRun yields a nightmarish 2050ms for this, > further investigation leads to the fact that most of the time is spent in the file primitive! > > Now thats some 2ms for a single directory entry! > [Just as a side note, ruby1.8 does the same job in 10ms :D] > ----------------------------------------------------------- > > primLookupEntryIn: fullPath index: index > <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin'> > > ----------------------------------------------------------- > > I think we should definitely add another primitive which directly lists > the file under a certain path. > > Of course this will break compatibility with existing code, but > I think the current approach does not scale... > > best > cami I have (FileDirectory default / 'package-cache') entries size 5053 [ (FileDirectory default / 'package-cache') entries ] timeToRun 2012 But if I run it in the Time Profiler, I get this: How do you manage to track the primitive ? Why/how would an extra primitive or better implementation of #entries break compatibility ? Sven

March 1, 2012