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

Re: [Pharo-project] pharo closures

by Igor Stasenko

On 25 March 2011 10:25, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > >> which paper? >> Is there something more than the blog? I read the old VW5 paper but eliot >> told me that this is old and not accurate with Cog anymore. > > Mmh... he was referring me to that "old" paper indeed. > http://www.esug.org/data/Articles/misc/oopsla99-contexts.pdf > > @igor that was exactly my point. You avoid copying temps around which you > might not need, and accesses to shared temps from your own frame keep on > having direct access rather than 1 indirection. But then again, this might > not pay off vs the speedup of the remote array in the long run depending on > the implementation details of the stack/jit VM, I clearly have no idea. It > would be cool to see some benchmarks that compare exactly having remote > arrays vs linked context frames but both on a stack. > If i'm not mistaken, remote temp vectors are rare.. (Eliot could give you a nice doit to count all closures in system which using temps vector) So if its even slow, its not a big deal anyways. > Unless I'm still completely missing the point and there's a grand JIT-reason > or other to not take the whole captured stackframe off... If this hasn't > been tried out yet I'd be interested in collaborating on that. I really > wonder what the speed diff is. > > cheers, > Toon > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011

Re: [Pharo-project] pharo closures

by Toon Verwaest

> which paper? > Is there something more than the blog? I read the old VW5 paper but eliot told me that this is old and not accurate with Cog anymore. Mmh... he was referring me to that "old" paper indeed. http://www.esug.org/data/Articles/misc/oopsla99-contexts.pdf @igor that was exactly my point. You avoid copying temps around which you might not need, and accesses to shared temps from your own frame keep on having direct access rather than 1 indirection. But then again, this might not pay off vs the speedup of the remote array in the long run depending on the implementation details of the stack/jit VM, I clearly have no idea. It would be cool to see some benchmarks that compare exactly having remote arrays vs linked context frames but both on a stack. Unless I'm still completely missing the point and there's a grand JIT-reason or other to not take the whole captured stackframe off... If this hasn't been tried out yet I'd be interested in collaborating on that. I really wonder what the speed diff is. cheers, Toon

March 25, 2011

Re: [Pharo-project] GUIs with Pharo / how to learn smalltalk

by Benjamin

About the "How to learn Morphic ?" point, there is a cool PharoCast that shows basis http://www.pharocasts.com/2011/02/pharo-gui-with-polymorph.html. About my own experience, I have learnt a bit by myself (RecentMessageList, Finder) and then I have pair programmed with Alain during last ESUG and learnt a lot :) There is some stuff you can't guess because they are strange and a bit disturbing (who said "layout" ? ^^), but then you can put some halt almost everywhere (let me give you an advice, first create a subclass, then put a halt ^^). But as said there is a lack of documentation, and I think than more pharocast could be a good way to change this. And since we are cleaning the system, I guess Morphic will come more and more understandable (I hope) ;) I wish you good luck and I you have question do no hesitate :) Ben On Mar 25, 2011, at 9:06 AM, StÃ©phane Ducasse wrote: > Hi Daniel > >> I have two questions, a technical one and a more general one. >> >> In broad strokes, what are people doing for GUIs? My guess would be using Morphic, but googling around you find more abuse than use, it looks like, and very little live links to up-to-date documentation. It makes me wonder: is there something other than Morphic which is being used? Or is everyone doing web apps? Or is there some other GUI toolkit I haven't found yet, and that's where all the action is? Whenever I see a neat Morphic window or something, I feel a bit like there's a party going on somewhere and I didn't get an invitation. Like the first rule of Morphic club is you don't talk about Morphic club. > > Not really truth. :) Now we are cleaning the system and trying to make sure that we understand it. > However it does not prevent you to learn. Look at Benjamin: (a smart second year students), he built Finder and now he is building > Nautilus. Start by looking at some examples and ask for feedback. People will help you. > Now this is clear that the documentation is not at the level it should be. > >> The general question I have is basically, am I the problem? > > No > >> Is it that the documentation isn't where I expect to find it, or in the form I'm used to seeing, or that it isn't relevant somehow in the Smalltalk universe? > > If you can VisualWorks there is a lot of documentation. > Now they have engineers too. > >> Or is it all really intuitive except for me? :) > > No I'm often puzzled too. The point is that I learn everyday more about the system and when I do not like the way it is done > I try to fix it. My main goal is to learn every day. Sometimes this is frustrating but in general it works. > >> I could accept that, I suppose, but how did you Smalltalk wizards become wizards? > > I do not know. But probably starting to read > - mailing-list > - read the code > - break it by putting the wrong self halt at the wrong place > The cool aspect of Pharo is that it is really improving day after day. > And that when there is something ugly you can be sure that one of these days we will fix it. Now we should go step by step. > > >> Did you just dive in and start reading the code in your own image? > > Yes. > When I started been an harvester for Squeak, here is what I did. > read the bug report (there was none so it was easy) > read the submitted code and if I do not understand pass to the next one > until I find something that I can understand > I still do that everyday. My goal is to have read a lot of the code. > >> Was there some master Smalltalk wizard that you knew who showed you how to do these things? > > I learned smalltalk alone. > Now if you can pair program with somebody this is much cooler. > You have pharoCasts, have a look at them. > >> I'm currently reading Smalltalk Best Practice Patterns > Excellent book > >> and it's one of the best programming books I've ever read. I see that there is a great deal of mastery of programming going around in Smalltalk circles, but I don't see the books that take you past beginner towards master, > > You have smalltalk by example (even if it is for VW I like it). It is more about design than Pharo by example and I would like to have one like that in the future but too busy right now. > >> other than SBPP. So what's the trick going on here? How did you guys become excellent? >> >> I hope none of this comes across as negative; > > Not at all. We know our problems > >> I think surely it's that I'm missing something. >> >> Thanks, >> >> â >> Daniel Lyons >> >> > >

March 25, 2011

Re: [Pharo-project] [ANN] Self-learning PocketCube Solver

by StÃ©phane Ducasse

:) What are the rules to play pocket cube? Is it like rubic cube? Stef > Hi, > > I am working on PocketCube solver (project wiki page here: > http://appdal.com/groups/36442/wiki/80aad/PocketCube_Solver_with_Pharo.html > ) > > My latest version of this can generate classes that can recognize pattern of > PocketCube. > If there is a PocketCubePattern subclass that matches current PocketCube it > gets used to solve it. > If there is not, a new pattern subclass gets created on the fly, and > continues to solve the PocketCube. > > Watch the demo video below. > > http://www.screencast.com/users/BaseballTeam/folders/Jing/media/d7db8f85-f8… > > Best Regards > > -- > View this message in context: http://forum.world.st/ANN-Self-learning-PocketCube-Solver-tp3404815p3404815… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 25, 2011

Re: [Pharo-project] "Does Committing Code to an Open Source Project Mean Committing Career Suicide?"

by Craig Latta

Wow. The stuff in there about California law is simply false. See the California labor code, sections 2870-2872 (e.g., at [1]). -C [1] http://law.justia.com/codes/california/2009/lab/2870-2872.html -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

March 25, 2011

Re: [Pharo-project] Brainstorming further out (was Re: What is the future of GUI in Pharo?)

by GÃ¶ran Krampe

A good post on the subject of Javascript remote debugging: http://www.em-motion.mobi/2010/10/12/on-device-javascript-debugging-intro/ regards, GÃ¶ran

March 25, 2011

[Pharo-project] Brainstorming further out (was Re: What is the future of GUI in Pharo?)

by GÃ¶ran Krampe

Hi all! <brainstorm> I think we should think about what is happening out there with the new explosion around two things: - Mobile apps - HTML5 IT is changing, people are using pads and phones more than computers in the very near future (or already). And HTML5 gives advanced capabilities to play on these devices without having to buy the whole technical eco system of them (on Android it is Dalvik and on iOS it is Objective-C more or less). HTML5 is enabling stuff like ThinVNC for example (just google it). Or endless mobile frameworks like Joapp.com etc. And then to top it off we have Google and it Nacl project (Native client) which is basically a "sandboxed x86 environment" if I grokked it correctly. I want to be able to develop systems in Pharo/Squeak that can reach people on all these devices - of basically two flavors: - Typical mobile apps using webtech. For many of us - for maximum reach and minimum "tie up" with any of these platforms I think the new web solutions are the way to go. - Graphical apps that look exactly like I want (think games). How do we enable this? One way could be to create a fast "Morphic player" layer in js utilizing HTML5 to talk back to a server side Squeak. Kinda like ThinVNC but tailored for Morphic? Or even more crazy, what if one could sit in the debugger in Pharo and "step into" code actually running inside the js engine in a browser, seamless debugging and somehow also seamless access to the objects on the js side? If someone here has seen how VW integrates with Gemstone (or perhaps GLASS does the same now) - it is very seamless. In that "crazy vision" one obviously starts thinking of two roads: 1. Create a "Smalltalk" on top of js that we can "tether with". JTalk perhaps? 2. Or perhaps it is even better to let js be js and instead make Muhammed (=Pharo) come to the mountain (=the huge js eco system). Thus we could create a low level tethering with Javascript and then make Pharo "Javascript aware" on many levels, like inspectors, debugger, browsers etc. ...hmmm, wow. Now that I am typing this the above #2 would be awesomely cool. ;) Another more "conventional" way to capture #1 above is of course to integrate Joapp or JQuery Mobile (Renggli already doing that I think) with Seaside. </brainstorm> regards, GÃ¶ran PS. Yes, this post didn't start with "I want to do X" but on the other hand I am just brainstorming here, I am not saying anyone should do *anything*. :)

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by Igor Stasenko

On 25 March 2011 09:22, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > StÃ©phane Ducasse wrote: >> >> the key problem is that if people do not jump in the water and decide to >> do something then nothing will happen beside reporting what other cool >> communities are doing. >> > > I fully agree what you are saying here ... personally I find the Morphic > learning curve waaaaaay to steep ... then again it may just be me :) > Heh.. take any GUI framework.. you will have same effect. It is naturally steep, because it tends to be big and complex. Because domain is quite big, and lies in a crossing of graphics and even handling. > > -- > View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3404804.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011

[Pharo-project] [ANN] Self-learning PocketCube Solver

by HwaJong Oh

Hi, I am working on PocketCube solver (project wiki page here: http://appdal.com/groups/36442/wiki/80aad/PocketCube_Solver_with_Pharo.html ) My latest version of this can generate classes that can recognize pattern of PocketCube. If there is a PocketCubePattern subclass that matches current PocketCube it gets used to solve it. If there is not, a new pattern subclass gets created on the fly, and continues to solve the PocketCube. Watch the demo video below. http://www.screencast.com/users/BaseballTeam/folders/Jing/media/d7db8f85-f8… Best Regards -- View this message in context: http://forum.world.st/ANN-Self-learning-PocketCube-Solver-tp3404815p3404815… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by Geert Claes

StÃ©phane Ducasse wrote: > > the key problem is that if people do not jump in the water and decide to > do something then nothing will happen beside reporting what other cool > communities are doing. > I fully agree what you are saying here ... personally I find the Morphic learning curve waaaaaay to steep ... then again it may just be me :) -- View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3404804.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 25, 2011