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

Re: [Pharo-project] Issue 3893 in pharo: PluggableListMorphOfMany better implementation of autoDeselect:

by pharo＠googlecode.com

Comment #3 on issue 3893 by Benjamin...(a)gmail.com: PluggableListMorphOfMany better implementation of autoDeselect: http://code.google.com/p/pharo/issues/detail?id=3893 Finally I hacked a bit and get the expected behavior Attachments: PluggableListMorphOfManyAutoDeselect.5.cs 2.8 KB

March 28, 2011

Re: [Pharo-project] Issue 3893 in pharo: PluggableListMorphOfMany better implementation of autoDeselect:

by pharo＠googlecode.com

Comment #2 on issue 3893 by Benjamin...(a)gmail.com: PluggableListMorphOfMany better implementation of autoDeselect: http://code.google.com/p/pharo/issues/detail?id=3893 I'm screwed because on mac, CMD+left click == right click ... So forget my previous cs and use this one Attachments: PluggableListMorphOfManyAutoDeselect.4.cs 2.7 KB

March 28, 2011

Re: [Pharo-project] Issue 3893 in pharo: PluggableListMorphOfMany better implementation of autoDeselect:

by pharo＠googlecode.com

Comment #1 on issue 3893 by Benjamin...(a)gmail.com: PluggableListMorphOfMany better implementation of autoDeselect: http://code.google.com/p/pharo/issues/detail?id=3893 Use this cs instead of the previous one Attachments: PluggableListMorphOfManyAutoDeselect.3.cs 2.6 KB

March 28, 2011

[Pharo-project] Issue 3894 in pharo: MenuMorph add:

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 3894 by Benjamin...(a)gmail.com: MenuMorph add: http://code.google.com/p/pharo/issues/detail?id=3894 when a add is done, it returns the MenuItemMorph created Attachments: MenuMorphAdd.2.cs 3.7 KB

March 28, 2011

Re: [Pharo-project] [Seaside] rack/wsgi/ring for smalltalk

by Sean Allen

Unified handling of how http messaging is done. Working on two different things that both need to do http messaging and it would be nice to have a single interface for them, additionally, it would be great to be able to register different steps along the way like... this is a handler routing... send everything under X path to this registered app/middleware bit. and be able to compose discreet parts together. ie, this handles file serving, this handles authentication and put them together into a single 'application'. basically i'm trying to do small simple parts, that are put together for more rest/resource oriented stuff. i did a rough run using ruby & rack + clojure & ring over the weekend to try and tease out the different parts and found that rack/ring were great to build on top of. also looking for the ability to add routing to application parts based on things like accept header and have built in automatic handling for different http codes that can then be hooked into and overridden but that is above a rack/ring/wsgi type interface. Sorry if this is kind of vague, I'm still working through what I want to do with some exploratory programming. 2011/3/28 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Hi Sean, > > What exactly would you like to achieve with Rack-like middleware? > > As I understood Rack is mostly a HTTP message composing/parsing > framework, so in short the HTTPRequest and HTTPResponse classes with all > accompanying infrastructure. We have that already in all our HTTP > projects, from Swazoo to WebClient and Zync, etc. > > What would be nice would be an unified HTTP messaging for all web > projects... > > Best regards > Janko > > On 28. 03. 2011 01:55, Sean Allen wrote: >> On Sun, Mar 27, 2011 at 2:42 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >>> >>> On 27 Mar 2011, at 19:13, Sean Allen wrote: >>> >>>> Is there a smalltalk equivalent for rack/wsgi/ring etc out there? >>>> >>>> I have an idea I'm going to play with that would be best served by >>>> building on something like rack. >>>> If there isn't one already, I'll implement one first and then move on >>>> to the idea that builds on it. >>>> If there is one, I'd rather see if it meets my needs and use it. >>>> >>>> Any pointers to anything appreciated. >>>> >>>> For Â anyone not familiar with rack et al: >>>> >>>> They are basically' middleware' layers providing a standard interface >>>> between webservers and applications. >>>> Middleware is a little deceptive... a better description might be that >>>> it is an interface that allows you to >>>> hook into between a webserver and other end points by either hooking >>>> up an application or middleware >>>> ( authentication, file serving ) that can be composed together as part >>>> of a specific application. >>>> >>>> http://rack.rubyforge.org/ >>>> https://github.com/mmcgrana/ring >>>> http://www.wsgi.org/wsgi/ >>> >>> Might be cool and useful. >>> I guess that Seaside's WAServerAdaptor concept comes very close. >>> It has the advantage that it's proven in the field, supporting many servers in different Smalltalk implementations. >>> But maybe you already knew this. >>> >> >> WAServerAdaptor isn't really much like ring, rack et al. >> But it does put the thought into my mind that it would be interesting >> down the road to >> try and take the Seaside infrastructure and work something like rack into it. >> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > >

March 28, 2011

[Pharo-project] Issue 3893 in pharo: PluggableListMorphOfMany better implementation of autoDeselect:

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 3893 by Benjamin...(a)gmail.com: PluggableListMorphOfMany better implementation of autoDeselect: http://code.google.com/p/pharo/issues/detail?id=3893 PluggableListMorphOfMany better implementation of autoDeselect:

March 28, 2011

Re: [Pharo-project] Issue 3866 in pharo: [Failing Test] 1.3 ReleaseTest.testUndeclared

by pharo＠googlecode.com

Updates: Status: FixToInclude Comment #1 on issue 3866 by marcus.d...(a)gmail.com: [Failing Test] 1.3 ReleaseTest.testUndeclared http://code.google.com/p/pharo/issues/detail?id=3866 cs attached fixes all undeclareds Attachments: UndeclaredRefsFix.1.cs 3.0 KB

March 28, 2011

[Pharo-project] Which methods are really not executed?

by Mariano Martinez Peck

Hi folks. I would like to know which are the messages that are not really executed, thus not being intercepted by proxies. So far, I know: 1) MessageNode >> initialize MacroSelectors := #( ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue: and: or: whileFalse: whileTrue: whileFalse whileTrue to:do: to:by:do: caseOf: caseOf:otherwise: ifNil: ifNotNil: ifNil:ifNotNil: ifNotNil:ifNil:). those are inlined by the compiler... 2) Special shorcut bytecodes that are in "Smalltalk specialSelectors" / "ParseNode classVarNamed: 'StdSelectors'" / "Smalltalk specialObjectsArray at: 24" Here I have a question...if I understand correctly, in this list of selectors there are 3 cases: 2.1) methods may or may not be executed depending on the receiver/arguments. For example 1 + 2 will never send the message #+ to 1. but 1 + 'mariano' will do. 2.2) methods that are NEVER sent, like #class and #== 2.3) methods that are ALWAYS sent, like #new, #next, #nextPut:, #size, etc. So...did I understand correclty this part? are there more cases where a message may not be really executed? thanks Mariano

March 28, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Camillo Bruni

>>> I don't care. I have it working for my "usage". This was just an example. >>> >>> And don't compare #class with all the boolean methods like #ifNil: and >>> friends or the bytecodes for integer operations....I think #class is >> sent >>> far less times than those... >>> >> >> Yes. and i predict that performance impact in macro benchmarks, where >> you running normal code >> (which not sending this message intentionally in a loop) will be at >> the noise level magnitude. >> > > So...what about doing something more real...for example, run all the > testcases and compare time. > Wouldn't that be a good "benchmark" ? sounds already better. make sure to run it something like 100 times, get the average and the standard deviation. otherwise the results don't provide much information. > BTW, can I run all test from code? (not using the TestRunner UI) something like the following code should do it. TestCase allSubclasses do: [ :cls| cls isAbstract ifFalse: [cls run]].

March 28, 2011

Re: [Pharo-project] [Seaside] rack/wsgi/ring for smalltalk

by Janko MivÅ¡ek

Hi Sean, What exactly would you like to achieve with Rack-like middleware? As I understood Rack is mostly a HTTP message composing/parsing framework, so in short the HTTPRequest and HTTPResponse classes with all accompanying infrastructure. We have that already in all our HTTP projects, from Swazoo to WebClient and Zync, etc. What would be nice would be an unified HTTP messaging for all web projects... Best regards Janko On 28. 03. 2011 01:55, Sean Allen wrote: > On Sun, Mar 27, 2011 at 2:42 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 27 Mar 2011, at 19:13, Sean Allen wrote: >> >>> Is there a smalltalk equivalent for rack/wsgi/ring etc out there? >>> >>> I have an idea I'm going to play with that would be best served by >>> building on something like rack. >>> If there isn't one already, I'll implement one first and then move on >>> to the idea that builds on it. >>> If there is one, I'd rather see if it meets my needs and use it. >>> >>> Any pointers to anything appreciated. >>> >>> For anyone not familiar with rack et al: >>> >>> They are basically' middleware' layers providing a standard interface >>> between webservers and applications. >>> Middleware is a little deceptive... a better description might be that >>> it is an interface that allows you to >>> hook into between a webserver and other end points by either hooking >>> up an application or middleware >>> ( authentication, file serving ) that can be composed together as part >>> of a specific application. >>> >>> http://rack.rubyforge.org/ >>> https://github.com/mmcgrana/ring >>> http://www.wsgi.org/wsgi/ >> >> Might be cool and useful. >> I guess that Seaside's WAServerAdaptor concept comes very close. >> It has the advantage that it's proven in the field, supporting many servers in different Smalltalk implementations. >> But maybe you already knew this. >> > > WAServerAdaptor isn't really much like ring, rack et al. > But it does put the thought into my mind that it would be interesting > down the road to > try and take the Seaside infrastructure and work something like rack into it. > > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

March 28, 2011