January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by StÃ©phane Ducasse

- One model can propose multiple spec. - Declarative. Now we should build more experience on it. Apparently vw people are happy with literal spec. Stef > Is there some fundamental difference > between Spec and ToolBuilder? > > Best > -Tobias > > Am 2012-01-12 um 16:57 schrieb Benjamin: > >> I have to work again on Spec and on this chapter to make it more sexy :) >> >> But basically, I think it can help to avoid having to don again and again the same UIs from scratch :) >> >> >

Jan. 12, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Tobias Pape

Is there some fundamental difference between Spec and ToolBuilder? Best -Tobias Am 2012-01-12 um 16:57 schrieb Benjamin: > I have to work again on Spec and on this chapter to make it more sexy :) > > But basically, I think it can help to avoid having to don again and again the same UIs from scratch :) > >

Jan. 12, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Benjamin

I have to work again on Spec and on this chapter to make it more sexy :) But basically, I think it can help to avoid having to don again and again the same UIs from scratch :) Ben On Jan 12, 2012, at 12:37 PM, StÃ©phane Ducasse wrote: >> >> I am all for people trying/prototyping new stuff, new ideas; that's one of the strong points of Smalltalk. >> >> However, I think/feel that for most Smalltalk developers, the combination of Language+Libraries+IDE in its current state is way better than anything else out there, why else would we keep using it, why else would we choose it above other environments ? >> >> In that perspective, I am a bit wary about people who want to change it all to make it so much better, especially if they are not experienced Smalltalkers. > > People should show and we will decide :) > >> BTW, what is the current state of Nautilus ? > > Benjamin is waiting for me to work on RPackage :( > Else it is working well. Now he started to implement all the widgets necessary to support refactoring > and since he started to get bored to redo all the time the same we started to explore reuse. > > Skip the beginning of this document and have a look at how we can reuse UI elements. > This is on my todo since mid december to read it calmly. > > <Spec.pdf> > >> >> When working with Camillo during the last sprint, he had Nautilus in his image and it seemed to work well. >> >> Sven >

Jan. 12, 2012

Re: [Pharo-project] Problem with Arch Linux and Cog

by Robert Sirois

Thanks for the response (everyone). Wilhelm, I appreciate your confidence in my skills as a programmer ;) but this type of debugging is a little beyond me. I may take this information and have someone locally help me out if possible. In the meantime, I have two other questions: 1) Is Pharo still deployable on Squeak. I guess for some reason I assumed it was only deployable with a Cog vm now, perhaps I misled myself?and 2) Are there any distributions of Linux that are true and tested, so to speak, with Pharo/Cog? Thanks!RS From: bschwab(a)anest.ufl.edu To: Pharo-project(a)lists.gforge.inria.fr Date: Wed, 11 Jan 2012 03:47:05 +0000 Subject: Re: [Pharo-project] Problem with Arch Linux and Cog You've clearly done the first thing I was going to recommend, which was to run Pharo from a terminal to capture any diagnostic output. The next step would be strace, which might reveal the vm's thoughts. Use either the -o option or redirect standard error to a file; strace writes nothing to stdout - you've been warned :) Once you get the output, it will be verbose, but grep is your friend in that case. You probably know this, something like cat strace-log.txt | grep uuid could be revealing. It might show where Cog thinks the library lives. It's ugly, but if you know where Cog insists on looking, then you can put symlink there and *maybe* get going. I just hit the problem I am describing (and suspect could be ailing you) on Ubuntu and hacked around it that way. Thanks to Nick for the strace pointer. If you are not sure if/where the UUID library lives, you can try the locate command, or otherwise scrounge around. If the library is not on the machine, that might be the problem. HTH. Bill From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Robert Sirois [watchlala(a)hotmail.com] Sent: Tuesday, January 10, 2012 10:20 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Problem with Arch Linux and Cog I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well. Was there any solution, or is the solution to not use Arch Linux? Related to this thread: http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.… http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.… Thanks, RS

Jan. 12, 2012

Re: [Pharo-project] Optimisation / Simplification ...

by Dennis Schetinin

http://live.exept.de/doc/online/english/programming/humor.html :) 2012/1/10 James Ladd <james_ladd(a)hotmail.com> > > While implementing Redline Smalltalk it occurred to me that methods and > blocks > are the same things, making the use of blocks to represent methods a > possible > optimisation or simplification to the internal of any Smalltalk > implementation. > > For example, > > at: key put: value > <statements here> > > Is not that different to: > > at:put: [ :key :value | <statements here> ] > > Just saying. > -- Dennis Schetinin

Jan. 12, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Denis Kudriashov

2012/1/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Did you publish your code? > So that we can have a look? > Yes, of course http://www.squeaksource.com/Presenty.html. But... :( - It is work on pharo1.1. - It is too young. It has not much "standart UI stuff" - Settings of presenty application is not stored with Monticello package. (it's just live prototype objects) - It has some bugs. But I really want improve it. I have two commercial applications based on Presenty which our clients used. And we improve it. So Presenty will be necessarilly improved Now I fix implementation of conceptual part of framework which give many new interesting stuff and bug fixing

Jan. 12, 2012

Re: [Pharo-project] Optimisation / Simplification ...

by Frank Shearar

And a method closes over the instvars of the object. Even if you said that at: key put: value <statements here> was equivalent to [:self :key :value | <statements here>] you'd still need to qualify that <statements here> has privileged access to the interior of self. So the equivalent block is more like [:self :key :value <insert all of the object's instvars> | <statements here>] (modulo non-local returns, of course) frank On 12 January 2012 13:23, Johan Brichau <johan(a)inceptive.be> wrote: > Hi, > > With the exception of any return statement in <statements here>, which should do a non-local return instead of returning from the block. > I just read an interesting post on why functions (or methods) are not blocks: http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ > > best, > Johan > > On 10 Jan 2012, at 01:52, James Ladd wrote: > >> >> While implementing Redline Smalltalk it occurred to me that methods and blocks >> are the same things, making the use of blocks to represent methods a possible >> optimisation or simplification to the internal of any Smalltalk implementation. >> >> For example, >> >> at: key put: value >> Â <statements here> >> >> Is not that different to: >> >> at:put: [ :key :value | <statements here> ] >> >> Just saying. > >

Jan. 12, 2012

Re: [Pharo-project] Optimisation / Simplification ...

by Johan Brichau

Hi, With the exception of any return statement in <statements here>, which should do a non-local return instead of returning from the block. I just read an interesting post on why functions (or methods) are not blocks: http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ best, Johan On 10 Jan 2012, at 01:52, James Ladd wrote: > > While implementing Redline Smalltalk it occurred to me that methods and blocks > are the same things, making the use of blocks to represent methods a possible > optimisation or simplification to the internal of any Smalltalk implementation. > > For example, > > at: key put: value > <statements here> > > Is not that different to: > > at:put: [ :key :value | <statements here> ] > > Just saying.

Jan. 12, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Dennis Schetinin

My 5 cents: I would like to have even wider capabilities to setup several dev. environments for different projects. For example, I see that as a browser that shows me a list of "environments" in the first panel (hiding those I don't need at the moment), and for each of them it allows me to add packages, individual classes, methods, tests, scripts, tasks (ToDo-s), inspectors, etc â in general any tool/window/morph (parametrized, if needed)â¦ maybe some smart objects (like searches, scripts). GUI development tools could be added as special kind of tools here. Extending the approach a bit further, I'd like this not to be just a single-window browser, but an endless field where I can place my "environments" and their components, link some of them together (i.e. organize them visually and semantically). Some navigation tools would be needed, of course. And BTW, Code Bubbles [ http://www.cs.brown.edu/~spr/codebubbles/demovideo.mov] is somewhat close to what I want. 2012/1/12 Stefan Marr <smalltalk(a)stefan-marr.de> > Hi: > > On 12 Jan 2012, at 12:56, Gerry Weaver wrote: > > > I guess some examples of what I'm wishing for would be: > > 1. A code editor that will allow editing a complete class in one go > (with code folding etc.) > > That is also the one and most important point for me. I always miss my > context. > Smalltalk's browser style where you need a new window for every semantic > entity just does the opposite. It hides away context/invariants and does > not allow my to benefit from my spacial+visual memory that helps to related > to code normally. > > Best regards > Stefan > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Dennis Schetinin

Jan. 12, 2012

Re: [Pharo-project] Cloudfork on Pharo under GLASS??

by Lawrence Kellogg

Hello Jan, On Jan 12, 2012, at 3:34 AM, Jan van de Sandt wrote: > Hello Larry, > > Cloudfork was developed on Pharo Smalltalk and ported to VW and VA Smalltalk. But not yet to Gemstone. We tried to isolate the platform specific code. Most of it is implemented as platform specific subclasses of CFPlatformServiceUtils. > > CloudforkAWS requires an XML parser, a SHA1 or SHA256 implementation and a HTTP client. I don't know if it has been done before but I think it should be possible to create a platform class for Gemstone that offers access to these functions. I don't have experience with Gemstone. The GLASS mailing list is probably the best source to ask. > Thanks for the explanation. Cloudfork is great, thanks for your work. I'll try to getting it working under GLASS but I don't have a lot of time. I got this response on the GS/SS Beta mailing list from James Foster: "Larry, Porting an application fromPharo to Version 3.0.1 should be similar to porting to 2.4.4.x. There are a number of new features (some, like FFI are necessary for you) and performance enhancements. On the other hand, people who have existing projects have not rushed to migrate from 2.x to 3.x so there is not as much production experience with Seaside on 3.x. I've been porting some of our tests to use FFI and have found a couple issues with the VM that should be fixed in 3.0.2 (schedule pending based on demand). I have also done a bit to improve the CHeader parsing. It is certainly our goal with FFI that it be fairly easy to use. In the last hour I've come up with the following in 3.1, and expect that it should be similar in 3.0.1. First, build a class that represents the library: | header class | header := CHeader path: '/usr/include/openssl/sha.h'. class := header wrapperForLibraryAt: '$GEMSTONE/lib/libcrypto.so'. class initializeFunctions. UserGlobals at: class name put: class. Next, use the library: | string result bytes | string := 'Now is the time for all good men to come to the aid of their party'. result := Crypto new SHA1_: string _: string size _: nil. bytes := result asArray collect: [:each | each codePoint]. result class -> bytes. String->anArray( 249, 92, 62, 72, 141, 165, 168, 163, 45, 23, 107, 2, 204, 233, 20, 250, 66, 180, 132, 37) I don't know anything about SSH-1, but this seems to match the info I found (using Google) at http://linux.die.net/man/3/sha. Do you think you would need much more? -James " Do you think this will be enough to get a working Cloudfork? Regards, Larry > Jan. > > > On Wed, Jan 11, 2012 at 8:29 PM, Lawrence Kellogg <mac.hive(a)me.com> wrote: > Hello, > I am in the process of moving my application over to GLASS. I had been developing using one-click Pharo with Cloudfork and all of my calls > to the Amazon services were working correctly. > > Now, I'm trying to do the same thing under Gemstone GLASS. I have loaded a bunch of the Cloudfork packages and > I am able to instantiate an S3 bucket in Amazon but I am running into authentication problems when I try to create something in the bucket, due to missing pieces of the > SHA1 class. Are there directions somewhere on how to set this up under GLASS? Has it been done before? > > Thanks for the help! > > Larry >

Jan. 12, 2012