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

[Pharo-project] [update 2.0] #20291

by Marcus Denker

20291 ----- Issue 6637: Unused global variable? http://code.google.com/p/pharo/issues/detail?id=6637 Issue 6616: ReleaseTest for RPackageOrganizer http://code.google.com/p/pharo/issues/detail?id=6616 -- Marcus Denker -- http://marcusdenker.de

Sept. 17, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 353 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 17, 2012

[Pharo-project] [update 2.0] #20290

by Marcus Denker

20290 ----- Issue 6620: Fix testRemoveTaggedClasses bad reference http://code.google.com/p/pharo/issues/detail?id=6620 ScriptLoader new unregisterPackage: 'Graphics'. ScriptLoader new unregisterPackage: 'RPackage'. ScriptLoader new addHomeRepositoryToAllPackages. -- Marcus Denker -- http://marcusdenker.de

Sept. 17, 2012

Re: [Pharo-project] [NB] Speaking about callbacks

by Igor Stasenko

On 17 September 2012 13:24, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 17.09.2012 12:28, Igor Stasenko wrote: >> >> This is not a big deal actually, >> since i will introduce a 'OO-callback' which performs a message send >> to an object using certain selector, >> it will be possible, of course, to pass the signature using other way, >> i.e. as an extra argument: >> >> callback := 3 createCallbackFor: #+ signature: #( int (int arg) ) >> >> as well as: >> >> callback := 3 createCallbackFor: #+ > > My 2c: > Does the behavior differ based on the objects class / dynamic state? > (In other words, are there multiple implementors? Does it use private > instvars to accomplish it?) private ivars? where? the callback implementation is 'private', since it is full of dark voodoo assembly code ;) , but its public interface won't put any special requirements to the object(s) to form a callback. It is just a message send, after all, so you just stating that when this callback get called a given object should receive that message (with callback arguments converted to smalltalk objects , of course), no more no less. The only thing with this kind of callbacks is their lifetime: it will be disposed once a receiver will turn to be garbage, which is logical, since it cannot longer receive any messages. But it even more convenient, because you don't need to keep the callback object around and manage its lifetime by yourself :) The only additional bounds, which make sense to put is to direct the type names/resolution via receiver's class, as well as different code generation options, which it may need. So, you don't have to globally define custom types (or be limited to use only already existing global types/aliases) Like that, if in scope of your class you have an alias 'foo' -> 'int' , you can use 'foo' as a type name in callback signature for an instance of that class. > If not, then I think 'OO-style' is a less elegant solution than keeping that > functionality/responsibility in a class more intricately linked to what it > is used for. > > The march towards the omniprescent Object which knows all, sees all and does > all is tangible, and, at least in my eyes, undesirable :) > well, it is just a convenience protocol for Object, allowing any object(s) to form callbacks. like currently we having #nbCall: , in same way i will add #nbCallback:... protocol (or something like that). > Cheers, > Henry -- Best regards, Igor Stasenko.

Sept. 17, 2012

Re: [Pharo-project] Sending email with Pharo

by Willem van den Ende

I've used SMTP with a mail server (Exim) installed on the same server for a small registration site. Haven't needed attachments. We did have one or two mails that weren't sent (don't know the exact cause, hard to reproduce). on the one hand, the SMTP is pretty low level, on the other hand, there is no magic, no external service to subscribe to or custom protocols. Attachment would involve creating a MIME-encoded piece of text, couldn't find one quickly by search engine. sample code, taken from app: sendText: text "Only works with locally installed SMTP server" |smtp| smtp := SMTPClient openOnHostNamed: 'your.host.com'. [ smtp initiateSession. smtp mailFrom: 'you(a)example.com' to: #('someone(a)somehwereelse.com') text: 'From: 'you(a)example.com'l Subject: your subject ', text. smtp quit. ] ensure: [smtp close] Note that you have to close the SMTP connection (it opens a socket to your mailserver that needs to be closed). Hope this helps, Willem On 15 September 2012 19:54, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi Hilaire, > > There was a post from Scott Sproule on using Amazon SES with zinc and > stunnel. > Sven, you remember? From the response it was not clear to me if he managed > to get everything working, and the need for stunnel might not be there > with the > current SSL support. SES is about 10% of the cost of postmaster. > > Attaching to mail is a well-known process. There are no problems there. > > Stephan > > > >

Sept. 17, 2012

Re: [Pharo-project] [NB] Speaking about callbacks

by Henrik Sperre Johansen

On 17.09.2012 12:28, Igor Stasenko wrote: > This is not a big deal actually, > since i will introduce a 'OO-callback' which performs a message send > to an object using certain selector, > it will be possible, of course, to pass the signature using other way, > i.e. as an extra argument: > > callback := 3 createCallbackFor: #+ signature: #( int (int arg) ) > > as well as: > > callback := 3 createCallbackFor: #+ My 2c: Does the behavior differ based on the objects class / dynamic state? (In other words, are there multiple implementors? Does it use private instvars to accomplish it?) If not, then I think 'OO-style' is a less elegant solution than keeping that functionality/responsibility in a class more intricately linked to what it is used for. The march towards the omniprescent Object which knows all, sees all and does all is tangible, and, at least in my eyes, undesirable :) Cheers, Henry

Sept. 17, 2012

Re: [Pharo-project] Smalltalkhub news

by Camillo Bruni

On 2012-09-17, at 11:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 17 Sep 2012, at 11:05, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> yeah, i think it is pointless to retry if you get 404 "not found" >> response. Usually (of course if web server conforms to HTTP RFC), this >> means that requested resource is really not there and will not be >> there anytime soon :) > > I decided to only do retries on NetworkError, ZnParseError for now, we'll see how it goes. > The ifFail block will be triggered on any Error. sounds reasonable :)

Sept. 17, 2012

Re: [Pharo-project] Zinc Progress

by Camillo Bruni

On 2012-09-17, at 11:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 17 Sep 2012, at 10:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Thanks again for the help, you made Pharo faster by removing my explicit Delays ;-) > > After fixing this in my working image, all MC operations just fly. > I am happy and sad at the same time. Sorry guys. haha :D if you have a nice design a performance issue per year is allowed :P

Sept. 17, 2012

Re: [Pharo-project] [NB] Speaking about callbacks

by Igor Stasenko

On 17 September 2012 12:06, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 17.09.2012 11:48, Igor Stasenko wrote: >> >> On 17 September 2012 11:19, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 16.09.2012 20:42, StÃ©phane Ducasse wrote: >>>> >>>> On Sep 16, 2012, at 7:17 PM, Igor Stasenko wrote: >>>> >>>>> So, i'd like to hear your input, which one you like, and which ones >>>>> you prefer to have >>>>> >>>>> 1. requires creating a subclass of NBFFICallback, overriding it's >>>>> fnSpec method. Takes a block closure as a callback. >>>>> 2. first you must create a factory object by specifying a callback >>>>> signature, then you can instantiate new callbacks by passing a block >>>>> closure to that factory >>>>> 3. to create a callback you must specify it's signature in one of the >>>>> compiled methods, and specify an object which will receive a message >>>>> when callback will be called. >>>> >>>> for what it is worth I like the 3rd form. Now I'm not sure on: is the >>>> right selector. >>>> >>> +1, out of those listed #3 seems the most convenient to use. >>> >>> Being able to do something like: >>> Integer >> #+ >>> <types: #( int (int aNumber) )> >>> >>> Then specify the callback parameter as >>> self callback: 3 with: #+ >>> >>> would be really neat. >>> >>> As an added bonus, it also highlights the problems this approach would >>> have >>> with simply annotating normal methods which utilize multiple >>> return/parameter types :) >>> >> not sure i understood your sentence about problems. >> > Integer + can return LargePositiveIntegers as well as SmallIntegers. > Argument type can be anything from float, to Fraction, to.. well, any kind > of number. > > So annotating such methods with a single <types> annotation (which is to > serve all uses of it as a callback), rather than defining signature on a > per-use basis can be somewhat limiting and end up working against the > inherent polymorphism you (at least when it comes to numerics) see in usual > smalltalk code. > > When it comes to return values that's mostly fine, you simply raise an error > if unable to convert to the specified type from what the smalltalk method > actually returns. > > But for parameters, you'd have to define separate methods per signature, say > addFloat: <types: #( int (float aNumber) )> > addUnsignedInt: <types: #( int (uint aNumber) )> > > when #+ actually handles those cases correctly. > > Maybe a way to "override" the default parameter signatures when specifying > the callback would be nice? > self callback: 3 with: #+ parameterTypes: {aNumber -> float} > > Leaves the usefulness of a default signature for a method, but enables you > to change it on a per-use basis, rather than pollute the base-image with > extra methods covering parametric variances. > Ah, yeah.. i get it. Thought the same way but asked for clarification. This is not a big deal actually, since i will introduce a 'OO-callback' which performs a message send to an object using certain selector, it will be possible, of course, to pass the signature using other way, i.e. as an extra argument: callback := 3 createCallbackFor: #+ signature: #( int (int arg) ) as well as: callback := 3 createCallbackFor: #+ the only difference between those two that upon creating a callback, in first you put signature explicitly, while in another one, NB will do a method lookup and then extract the signature from that method (or raise an error, if signature cannot be found). > Cheers, > Henry -- Best regards, Igor Stasenko.

Sept. 17, 2012

[Pharo-project] Topics for a term project in CG

by Dennis Schetinin

Hello! My student is looking for a topic for her term project/paper in area of Computer Graphics and UI maybe. I didn't pay enough attention to this area for some time, so I ask if there are some tasks we could help to solve here? Please note, she has no strong background in CG. One topic could be something about Morphic, but what is it exactly? Or any other idea is welcome also. And one more thing: our university imposes some additional requirements thus not every practically useful topic can be accepted, I'll have to select so more ideas is better. TIA for any help. Best regards, Dennis Schetinin

Sept. 17, 2012