- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by Guillermo Polito

I think it is important a team working on application integration (Soap, rest servers, xml and binary rpc, C/Java/ .Net integration) for the enterprise pharo user :). On Fri, Jul 1, 2011 at 9:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > > > > I think we should try this. IMO a task around SUnit & friends is missing. > > sign in for it and lead it. > What I would like is a small agenda so that other people can see what is > happening > and if they want to help join. > > > > > Laurent. > > >

July 1, 2011

Re: [Pharo-project] Cog VM continuous integration: update

by Eliot Miranda

On Fri, Jul 1, 2011 at 12:40 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 01/07/11 8:54 AM, Igor Stasenko wrote: > >> >> The next step is to run tests for built VMs. For this i planning to >> create a specialized package, which will contain code snippets for >> loading& firing off various tests, >> because currently all tests are a bunch of .st scripts, and managing >> files over dozen of networked machines is not fun. >> So, i think i will just take these snippets and put them into single >> MC package, so then it could be managed much easier. >> > > Building VM's on CI server is a great step forward. Thanks for making it > happen. > > I'm curious about how to test each build. For a C compiler, typically a > fixed-point is done - i.e. compile the new compiler (yielding stage1 > compiler), then use the stage1 compiler to compile the new compiler again > (yielding stage2 compiler). Repeat to get stage3 compiler. The stage2 and > stage3 compiler binaries are supposed to be identical. Then, in a C/UNIX > system, recompiling the OS and tools was a good test suite. > > There may be some equivalent thing to do for a JIT/VM + image, but I can't > figure out what it is. Maybe all the method dictionaries need to be written > out in canonical order, then the stage2 and stage3 results compared. But, > that would only test the compiler, not the JIT functionality. Anyways, just > some random thoughts... > ? The VM source is generated in a canonical order (essentially alphabetic by function, but with exceptions; the interpret interpreter main loop comes first). This source is pure C and compiled with the C compiler. The VM is tested by running tests in the image while running above the VM. HTH -- best, Eliot

July 1, 2011

Re: [Pharo-project] Cog VM continuous integration: update

by Yanni Chiu

On 01/07/11 8:54 AM, Igor Stasenko wrote: > > The next step is to run tests for built VMs. For this i planning to > create a specialized package, which will contain code snippets for > loading& firing off various tests, > because currently all tests are a bunch of .st scripts, and managing > files over dozen of networked machines is not fun. > So, i think i will just take these snippets and put them into single > MC package, so then it could be managed much easier. Building VM's on CI server is a great step forward. Thanks for making it happen. I'm curious about how to test each build. For a C compiler, typically a fixed-point is done - i.e. compile the new compiler (yielding stage1 compiler), then use the stage1 compiler to compile the new compiler again (yielding stage2 compiler). Repeat to get stage3 compiler. The stage2 and stage3 compiler binaries are supposed to be identical. Then, in a C/UNIX system, recompiling the OS and tools was a good test suite. There may be some equivalent thing to do for a JIT/VM + image, but I can't figure out what it is. Maybe all the method dictionaries need to be written out in canonical order, then the stage2 and stage3 results compared. But, that would only test the compiler, not the JIT functionality. Anyways, just some random thoughts...

July 1, 2011

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by Tudor Girba

Hi, The idea of Pharo Tasks is not to get things rigid and to stop the individuals from contributing. This should continue to happen. Instead, the idea is to start acknowledging that Pharo has became larger, and that the integration and drive of individual contributions has more dimensions that can be handled by the core group alone. So, the Pharo Task Force is a mechanism for teams to form around some larger topics. Like I said beforetime, I want to work on the IDE. This is a topic that is larger than one person can and should do. But, it is also a topic that requires integration of contributions, and it won't work by simply doing a union of choices. Just like now the Core team relentlessly cleans up the language and infrastructure, so should the IDE deserve a similar approach to get it strong and reinvented. People should know that this project exists and that they can contribute in a more organized way. This won't work by force. But, if someone wants to build/lead/integrate a project like this, I think it can work nicely. Cheers, Doru On 1 Jul 2011, at 13:08, Igor Stasenko wrote: > Are you trying to repeat experience of Squeak teams? > I can remind you that they are never worked and failed in the end. > > And i think that problem is that its hard to coordinate people which > are located around the globe and their main tasks are completely > different. > Another reason is that you cannot enforce any kind of responsibility > for delaying or not delivering , because we're talking about > enthusiasts. > > I believe that individual people with own vision and own, personal, > agenda could do much more. > If someone would like to voluntary coordinate some activities, i am > all for it. Now this means that given person should have plan in his > head and stick with it, > and keep an eye, ask around, communicate, and of course try coordinate people. > But is it really need to be formalized like that? > > We, as community could discuss the agendas, and then a concrete steps > to implement it. Now, its not really matters who will do it, as long > as there enough people interested in helping > with it. > And its completely pointless to form groups of individuals, only to be > listed as a group member on site and doing nothing (for whatever > objective reason). > > So, the right questions about any improvement, which we would like to > see in future is: > - do/why we need that > - who can do that > > if both of these questions can be answered positively, then it is only > a matter of time for new feature to appear. > And to my opinion, putting any kind of formality around it is > completely orthogonal to what will happen in reality. > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "Some battles are better lost than fought."

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Sven Van Caekenberghe

On 01 Jul 2011, at 20:33, Matt Kennedy wrote: > I could see some value to supporting an asZnEntity protocol. As an example, say I have an API which needs to support various output formats. I could build my classes to use the appropriate entity builder when responding to asZnEntity so that in the server code I only need to do ZnResponse ok: myresponse asZnEntity, or just ZnResponse ok: myresponse if ok: sends asZnEntity. Yes, that is indeed possible, although I am not sure if lots of asXX methods all over are a good idea. The problem is that there is no really useful one to one mapping between Smalltalk objects and Entities. An Entity has a content type (mime type) and a content length (rendered byte size) and knows how to represent itself on a binary stream or read itself from a binary stream. Now, given a String or a ByteArray, it is indeed possible to quickly convert to an Entity (ZnEntity class>>#with: does that). But that is not enough: one has to indicate a useful content type (ZnEntity class>#text: and #html: are examples of doing this automatically). In general though, there is no way to hide the need to set the actual type (ZnEntity class>>#with:type:). So you need #asZnEntityOfType: which would add parenthesis again. Sven

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Matt Kennedy

I could see some value to supporting an asZnEntity protocol. As an example, say I have an API which needs to support various output formats. I could build my classes to use the appropriate entity builder when responding to asZnEntity so that in the server code I only need to do ZnResponse ok: myresponse asZnEntity, or just ZnResponse ok: myresponse if ok: sends asZnEntity. Matt On Jul 1, 2011, at 11:12 AM, Igor Stasenko wrote: > On 1 July 2011 16:55, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 01 Jul 2011, at 15:52, Janko MivÅ¡ek wrote: >> >>> I'd just introduce yet that ZnResponse ok: 'Hello world'. To cover the >>> most common response body and this will be really easy to grasp for >>> newcomers. Nothing specially to learn upfront, just that simple two >>> lines with seamless way to respond with some text. >>> >>> This complicate a bit Zinc internals, but the gain on simplicity on API >>> level is IMHO worth that. >> >> I saw your code, and I considered it, but it feels too much out of place (the implementation that is), architecturally wrong and not that usefull. Although ZnResponse ok: (ZnEntity text: 'Hello World!') is longer it is also more intention revealing, it tells you something about HTTP without being too verbose. >> >> These are opinions and aesthetics, of course. >> > > IMO. API should be focused on most often use cases. Not on useless > cases , like showing 'hello world'. > Because going that road, you will just ruin the beautiful design of > what you really need in favor of supporting useless things. > >> Sven > > > > -- > Best regards, > Igor Stasenko AKA sig. >

July 1, 2011

Re: [Pharo-project] Please test Pharo 1.3!

by Mariano Martinez Peck

On Fri, Jul 1, 2011 at 9:10 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > > > - Script Manager is broken: adding a script produces an error > > > > > > > Torsten, can you take a look? > > > When I downloaded a fresh Pharo-dev 1.3 from Hudson this morning > I was not able to reproduce this. ScriptManager worked without a > problem. > > The only problem I noticed was that there was no styling > (which is fixed by replacing MorphicTextEditor with PluggableTextMorph > in a new "ScriptManager-Core-tbn.13"). > > thanks > Feel free to integrate this version. > > done > > It would also nice if ScriptManager would support autocompletion > but I got lost in all these completionController stuff... > If anyone knows how to apply it feel free to have a look. > > Dont know about the state of completion these days ... but it > would be nice if this would just be an option one sets on the editor. > > Bye > T. > > -- > NEU: FreePhone - kostenlos mobil telefonieren! > Jetzt informieren: http://www.gmx.net/de/go/freephone > -- Mariano http://marianopeck.wordpress.com

July 1, 2011

Re: [Pharo-project] Cog VM continuous integration: update

by Tudor Girba

Great work! I will test the VM as soon as I can. Thanks, Doru On 1 Jul 2011, at 16:16, Igor Stasenko wrote: > On 1 July 2011 15:56, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Jul 1, 2011, at 2:55 PM, Igor Stasenko wrote: >>> >>> So, after couple of hiccups and show-stoppers now everything more-or >>> less run smoothly on Hudson, (except from stack vm on win32). >>> >> Very nice!!! >> >> What this VM has (as it merges all changes of Igor) is support for Ephemerons. >> >> The ephemerons-imageside.3.cs from http://code.google.com/p/cog/issues/detail?id=44 >> has the image side. >> > > Yes, and it contains a long awaited fix for problems with large images > on windows. So i'd like to hear from Tudor if it works for him. > http://code.google.com/p/cog/issues/detail?id=46 > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "One cannot do more than one can do."

July 1, 2011

Re: [Pharo-project] Cog VM continuous integration: update

by Mariano Martinez Peck

Igor, thank you so much for the push. I know that the merge was not easy at all and neither setting up the windows slave. I cannot say more than just thank you. On Fri, Jul 1, 2011 at 4:16 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 1 July 2011 15:56, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On Jul 1, 2011, at 2:55 PM, Igor Stasenko wrote: > >> > >> So, after couple of hiccups and show-stoppers now everything more-or > >> less run smoothly on Hudson, (except from stack vm on win32). > >> > > Very nice!!! > > > > What this VM has (as it merges all changes of Igor) is support for > Ephemerons. > > > > The ephemerons-imageside.3.cs from > http://code.google.com/p/cog/issues/detail?id=44 > > has the image side. > > > > Yes, and it contains a long awaited fix for problems with large images > on windows. So i'd like to hear from Tudor if it works for him. > http://code.google.com/p/cog/issues/detail?id=46 > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Mariano http://marianopeck.wordpress.com

July 1, 2011

[Pharo-project] About HTTP

by stephane ducasse

Hi guys I'm writing with olivier a chapter for the seaside book on REST and olivier uses curl to analyse the contents of request and answers and I would like to see if we can do it in Pharo. Now can I run zinc in another image and spy the requests? Stef

July 1, 2011