- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.3] #13208
by Marcus Denker May 22, 2011

May 22, 2011

13208 ----- Issue 4160: HelpSystem is Dirty in Full Issue 4254: StandardSourceFileArray should go -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] [Hudson] Jenkins
by Marcus Denker May 22, 2011

May 22, 2011

On May 22, 2011, at 11:39 AM, Geert Claes wrote: > No no, I have heard about these network admin nazi's and I feel for you :) > Either we use existing infrastructure, or we don't. Honestly, I did not ask them if it's possible to change the logo because *at this point* I would feel silly to do so. There are more important things to do now. Really. For example *using* the Jenkins setup. This will not happen by itself. I can either burn my time changing Logos, or I can do it doing things that are important. > Just forget my suggestion, branding and marketing have never really been > Smalltalk's problem ;) > Yes, Pharo will fail because the Jenkins shows the Jenkins Logo. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] [Hudson] Jenkins
by Marcus Denker May 22, 2011

May 22, 2011

On May 22, 2011, at 8:55 AM, Geert Claes wrote: > > Marcus Denker-4 wrote: >> >> The problem is that this is a company wide installation serving many >> projects... >> Pharo is just one of them. >> > > But everything is Pharo based and even the URL includes "Pharo" does it not? > Yes, the IT services provide infrastructure that creates Jenkins setups. E.g. we can request one for RMOD, and there will be one for Rmod. Yes, we could request them to extend this meta-setup it with changing the look. But the thing is that this *We* can not do, but the admines would need to do it. And it would be work to provide a UI for uploading images, checking they are good... And my feeling is that they have other things that are more important to do (the whole setup is in test mode...) Especially we should *use* it before running back and requesting even more changes. (and unimportant ones, especially)... It's just not a good idea to do that now. Marcus > -- > View this message in context: http://forum.world.st/Hudson-Jenkins-tp3538245p3541662.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

Re: [Pharo-project] [Hudson] Jenkins
by Marcus Denker May 22, 2011

May 22, 2011

On May 21, 2011, at 7:54 PM, Geert Claes wrote: > Hi Marcus, Maybe you could replace the resource images with the attached > images - replaced "Jenkins" with "Pharo" :) > The problem is that this is a company wide installation serving many projects... Pharo is just one of them. > Re-branding: > > http://forum.world.st/file/n3540934/title.png title.png > http://forum.world.st/file/n3540934/jenkins.png jenkins.png > http://forum.world.st/file/n3540934/topbar.png topbar.png > > -- > View this message in context: http://forum.world.st/Hudson-Jenkins-tp3538245p3540934.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] Set with nil
by Guillermo Polito May 21, 2011

May 21, 2011

Hi! Since a year ago, we have this issue: http://code.google.com/p/pharo/issues/detail?id=1907 There were 2 solutions proposed, and the 2 were developed by different people. But for some reason it was not integrated and continuously postponed. So, my question is: Do we want Sets accepting nil? If we don't, the issue is invalid. If we do, can someone review the code proposed? Thanks! Guille

8 10

[Pharo-project] VW's ObjectRegistry similar in Pharo?
by Mariano Martinez Peck May 21, 2011

May 21, 2011

Hi guys. We are doing graph traversal (for Fuel) and we would love a collection to be really fast and only support two simple operations: #add: and #includes: The idea is that each object we process of the graph we put it in the collection and then for each object we have to ask whether it is included or not (to avoid cycles and putting the same object more than once). VW seems to have ObjectRegistry (subclass of IdentitySet) which is more or less that. It is used by ObjectTracer, which in fact is what we want to do. And even more, Parcels uses that ;) (or an extension of that). So...I wonder, is there a special collection implementation ideal for this case? is something similar to ObjectRegistry available for pharo ? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

2 2

[Pharo-project] [Hudson] Jenkins
by Marcus Denker May 21, 2011

May 21, 2011

Yes! https://ci.lille.inria.fr/pharo/ All existing accounts should work, but it is empty right now. We will test it a bit and then think about how to move all configs there. This setup has the possibility of defining a "staging" project. This is run as soon as an updated jenkins is available and on green --> the whole installation updates to the latest jenkins automaticaly. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

4 3

Re: [Pharo-project] [squeak-dev] My solution to handling errors in system-critical processes
by Igor Stasenko May 21, 2011

May 21, 2011

On 20 May 2011 19:33, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, > Â Â Â I get the idea but I does one really need on:fork: ? Â Why not add > Exception>fork, a la Exception>pass? Â So one writes > [ self doSomething Â ] on: Error do: [:ex | ex fork ]. > and if you want to specify a handler function you pass in a block: > > [ self doSomething Â ] on: Error do: [:ex | ex fork: [block to handle error > in another process here] ]. Good question. You can implement it anywhere. Except then how to correctly determine stack slicing point? Exception>>fork: aBlock contextToSlice := thisContext sender home ? see, the above is too fragile. Where the guarantees that you sending #fork: inside a block, but not like: Error new fork: [ .... ] ? If you looked at implementation, i capturing the context of a method before sending #on:do: in this way, i know the stack slicing point beforehand. But if i place it into exception, then correct behavior will have to rely on developer's sanity that he using it as intended by design. So, why putting pitfalls when we can avoid them? My choice for stack slicing point was to let user to see the closure context with on:do: while debugging, otherwise it will be harder to determine the origin of code, which led to error. Right now, if you evaluate [ 1/0 ] on: Error fork:[ :ex | ex pass ] in debugger, you will see the 2nd bottom context will be an on:do: method, and next one will contain the context for closure that is receiver of #on:do: so in this way you can clearly see the method with exception handler, who wanted to handle errors in forked process. > ? > Further, re the finalization issue why are you so resistant to the > tried-and-tested VW solution that's been in use for about a decade? i am not resistant at all. I had no time to do that. Actually, i came to this idea when looking at Henrik's code for Announcements.. and then i found that it can serve for both finalization and Announcements (and lot of other critical places, where you don't want to be killed by errors). For instance , today i shown to Stef, that by placing it at single point in WorldState>>doOneCycleNowFor: aWorld we could avoid respawning UI process each time you open debugger. You slicing the stack with error, putting it into forked process, where you can do anything with it, while UI process continues to run from known safe point. So it solves more problems than just in finalization. Also i think that it is more efficient: you pay the high price only when it is necessary - when exception happens, but if things go as expected , the overhead is minimal. While in solution which you describing, the price was higher, since you have to pass the finalizer to forked process and signal semaphore, and then wait till it finish or fork another process. And synchronization is not cheap, and moreover, you will have 1 extra process hanging around all the time. While now i can simply do: executors do: [:executor | [ executor finalize ] on: Exception fork: [ :ex | ex pass ] ] > best, > Eliot -- Best regards, Igor Stasenko AKA sig.

2 3

[Pharo-project] The Cult of Done Manifesto
by Marcus Denker May 21, 2011

May 21, 2011

The Cult of Done Manifesto - There are three states of being. Not knowing, action and completion. - Accept that everything is a draft. It helps to get it done. - There is no editing stage. - Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it. - Banish procrastination. If you wait more than a week to get an idea done, abandon it. - The point of being done is not to finish but to get other things done. - Once you're done you can throw it away. - Laugh at perfection. It's boring and keeps you from being done. - People without dirty hands are wrong. Doing something makes you right. - Failure counts as done. So do mistakes. - Destruction is a variant of done. - If you have an idea and publish it on the internet, that counts as a ghost of done. - Done is the engine of more. http://www.brepettis.com/blog/2009/3/3/the-cult-of-done-manifesto.html?v=1 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

8 8

[Pharo-project] SerialPort Plugin Patches.
by Friedrich Dominicus May 21, 2011

May 21, 2011

I've downloaded the Cog sources and checked the SerialPlugin stuff. I'd like to use it with the patches that will make it work on Linux also but for that there should be a primite with printPortByName or the like, but it's not in the actual sources. So can anyone tell me where an actualiced SerialPlugin is, with which I then can use strings for accessing the serial lines? Thanks Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

1 0