- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3885 in pharo: MultiNewParagraphWithSelectionColor should be moved to Deprecated13

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3885 by marcus.d...(a)gmail.com: MultiNewParagraphWithSelectionColor should be moved to Deprecated13 http://code.google.com/p/pharo/issues/detail?id=3885 in 13113

March 28, 2011

Re: [Pharo-project] Issue 3886 in pharo: Move PointerFinder to Deprecated13

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3886 by marcus.d...(a)gmail.com: Move PointerFinder to Deprecated13 http://code.google.com/p/pharo/issues/detail?id=3886 in 13113

March 28, 2011

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

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 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 in 13113

March 28, 2011

Re: [Pharo-project] Issue 2450 in pharo: halt in TTFontReader >>processCompositeGlyph:contours:from:

by pharo＠googlecode.com

Updates: Status: Closed Comment #6 on issue 2450 by marcus.d...(a)gmail.com: halt in TTFontReader >>processCompositeGlyph:contours:from: http://code.google.com/p/pharo/issues/detail?id=2450 in 13113

March 28, 2011

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