November 2014 - Pharo-users

Re: [Pharo-users] Porting to a MAC

by garduino

stepharo wrote >> About Dolphin, well, as you point, the ability to generate an exe and >> some >> other features more of the side of publishing a commercial app, make hard >> to >> abandon it (also the UI builder). > > Yes we would love to have the same facilities. > This is why we worked on Fuel because we would like to have a better > deployement (but this is orthogonal to deliver dll). > We would love people to work on that. Even when Dolphin can generate dll's, to my point of view is more important the capacity of generate a standalone executable (for Windows operating systems) and the ability of behave as a native application (multiple windows for example). -- View this message in context: http://forum.world.st/Porting-to-a-MAC-tp4788105p4788374.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 4, 2014

Re: [Pharo-users] Memoization Question

by Denis Kudriashov

2014-11-04 16:09 GMT+03:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > The language you are thinking of is most probably PHANtom: > http://pleiad.cl/phantom > Exactly

Nov. 4, 2014

Re: [Pharo-users] Memoization Question

by Johan Fabry

The language you are thinking of is most probably PHANtom: http://pleiad.cl/phantom But (as author of the language) I think it is overkill to use it for just a memoization cache. Idem for AspectS (I donât know if it works on Pharo though). Right now, I would use MethodWrappers instead, and when Reflectivity is working use that. On Nov 4, 2014, at 1:50 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi > > There is AspectS package at old squeaksource site. I not know is it working in Pharo. > And there was presentation at Esug few years ago about another implementation of aspects in Pharo ( i not remember project name) > > 04 Ð½Ð¾ÑÐ±. 2014 Ð³. 9:04 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "phil(a)highoctane.be" <phil(a)highoctane.be> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > Le 3 nov. 2014 22:13, "Hilaire" <hilaire(a)drgeo.eu> a Ã©crit : > > > > What's wrong with? > > > > myData > > ^ data ifNil: [data := self computeMe] > > That I do have a lot of places like this and do not want these data littering the code. > > Aspects would solve this but we do not have that. > > Also I need the mechanism to be removable. > > So, I read something about MethodWrapper, ghost, slots... Can't one use any of these things to do this memoization cleanly? > > Phil > > > > > > > > > Le 03/11/2014 16:10, phil(a)highoctane.be a Ã©crit : > > > How can I do memoization in Pharo? > > > > > > I mean, a generic mechanism that will help me wrap the caching around > > > the method invocations / messages. > > > > > > I have expensive calls that do not have to refresh their results as > > > often as they are called. > > > > > > TIA > > > Phil > > > > > > -- > > Dr. Geo - http://drgeo.eu > > iStoa - http://istoa.drgeo.eu > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Nov. 4, 2014

Re: [Pharo-users] How not to serve an AngularJs application from Pharo

by kilon alios

I have welcomed Amber with open arms, but I have failed miserably to wrap my head around it. Is ironic if you think about, Pharo really lacks documentation even in basic areas, libraries are nowhere near as powerful as those offered by javascript yet I have found Pharo way easier to use. Web development looks to me like a big pile of unnecessary mess. Actually Amber is the best part of it :D So the problem for me is not so much the System Browser , but the steep learning curve . Or maybe its just the fact that I dont like many of the web frameworkds, including html / js / css etc. I wish I could make something in pharo and click a button to deploy it as a website but alas thats just a dream. I think however that for the amount of developers Amber has been making some amazing progress. On Tue, Nov 4, 2014 at 4:55 AM, Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Mon, Oct 27, 2014 at 10:21:18PM +0200, kilon alios wrote: > > Even though I always have been a supporter of Amber the IDE has still a > > very long way to go. > > I've been meaning to build a code browser for Amber (and GST) in Pharo with > Omnibrowser using the Shampoo protocol[1], once I get some copious spare > time. > > [1] http://dmitrymatveev.co.uk/shampoo > > Pierce > >

Nov. 4, 2014

Re: [Pharo-users] Memoization Question

by Denis Kudriashov

Hi There is AspectS package at old squeaksource site. I not know is it working in Pharo. And there was presentation at Esug few years ago about another implementation of aspects in Pharo ( i not remember project name) 04 Ð½Ð¾ÑÐ±. 2014 Ð³. 9:04 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "phil(a)highoctane.be" <phil(a)highoctane.be> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > Le 3 nov. 2014 22:13, "Hilaire" <hilaire(a)drgeo.eu> a Ã©crit : > > > > What's wrong with? > > > > myData > > ^ data ifNil: [data := self computeMe] > > That I do have a lot of places like this and do not want these data > littering the code. > > Aspects would solve this but we do not have that. > > Also I need the mechanism to be removable. > > So, I read something about MethodWrapper, ghost, slots... Can't one use > any of these things to do this memoization cleanly? > > Phil > > > > > > > > > Le 03/11/2014 16:10, phil(a)highoctane.be a Ã©crit : > > > How can I do memoization in Pharo? > > > > > > I mean, a generic mechanism that will help me wrap the caching around > > > the method invocations / messages. > > > > > > I have expensive calls that do not have to refresh their results as > > > often as they are called. > > > > > > TIA > > > Phil > > > > > > -- > > Dr. Geo - http://drgeo.eu > > iStoa - http://istoa.drgeo.eu > > > > > > >

Nov. 4, 2014

Re: [Pharo-users] Memoization Question

by Norbert Hartl

> Am 04.11.2014 um 12:47 schrieb phil(a)highoctane.be: > > On Tue, Nov 4, 2014 at 12:06 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > I'm not sure. I thought Spy would use them but it does not load in a fresh pharo3 for me. Did you try > > http://www.squeaksource.com/ObjectsAsMethodsWrap/ <http://www.squeaksource.com/ObjectsAsMethodsWrap/> > > This one loads and tests are green once the "_"s are replaced with ":="s > > Thx for the pointer. I'll see how I can hook a TTLCache into this. > I don't know your exact use case. But if you need one cache for your package with TTLCache then this could be done in one pass. You can have an installer that scans your package for methods containing a special pragma. Then you exchange every compiled method (installing the wrapper) with the wrapper that accesses its value from the same TTLCache having the compiled method as key. So you would have exchanged a lot of methods that share a single cache. As the TTLCache gives the hit rate on printString you get back an effectivity number for free. Norbert > Phil > > ? > > Norbert > >> Am 04.11.2014 um 11:53 schrieb phil(a)highoctane.be <mailto:phil@highoctane.be>: >> >> On Tue, Nov 4, 2014 at 9:59 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> Ghost won't be a big help here. Slots would be a good solution but not if it needs to be removable on runtime. So it seems MethodWrappers is your best bet. I'd try create a caching MethodWrapper, mark all the needed methods with a pragma and then install the MethodWrapper on these. Could be a package wide install/uninstall if you need that. >> >> I loaded MethodWrappers in 3.0 as I saw in http://forum.world.st/MethodWrappers-td3829576.html#a4601624 <http://forum.world.st/MethodWrappers-td3829576.html#a4601624> >> >> Gofer it >> squeaksource: 'MethodWrappers'; >> package: 'MethodWrappers4'; >> load. >> >> It loads. >> >> But no test seems to be fine. >> >> >> <image.png> >> >> What version should I be using? >> >> Phil >> >> Norbert >> >> Am 04.11.2014 um 07:03 schrieb "phil(a)highoctane.be <mailto:phil@highoctane.be>" <phil(a)highoctane.be <mailto:phil@highoctane.be>>: >> >>> >>> Le 3 nov. 2014 22:13, "Hilaire" <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu>> a Ã©crit : >>> > >>> > What's wrong with? >>> > >>> > myData >>> > ^ data ifNil: [data := self computeMe] >>> >>> That I do have a lot of places like this and do not want these data littering the code. >>> >>> Aspects would solve this but we do not have that. >>> >>> Also I need the mechanism to be removable. >>> >>> So, I read something about MethodWrapper, ghost, slots... Can't one use any of these things to do this memoization cleanly? >>> >>> Phil >>> >>> > >>> > >>> > >>> > Le 03/11/2014 16:10, phil(a)highoctane.be <mailto:phil@highoctane.be> a Ã©crit : >>> > > How can I do memoization in Pharo? >>> > > >>> > > I mean, a generic mechanism that will help me wrap the caching around >>> > > the method invocations / messages. >>> > > >>> > > I have expensive calls that do not have to refresh their results as >>> > > often as they are called. >>> > > >>> > > TIA >>> > > Phil >>> > >>> > >>> > -- >>> > Dr. Geo - http://drgeo.eu <http://drgeo.eu/> >>> > iStoa - http://istoa.drgeo.eu <http://istoa.drgeo.eu/> >>> > >>> > >>> > >> > >

Nov. 4, 2014

Re: [Pharo-users] Memoization Question

by Luc Fabresse

2014-11-04 13:16 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 04 Nov 2014, at 09:59, Norbert Hartl <norbert(a)hartl.name> wrote: > > Ghost won't be a big help here. Slots would be a good solution but not if > it needs to be removable on runtime. So it seems MethodWrappers is your > best bet. I'd try create a caching MethodWrapper, mark all the needed > methods with a pragma and then install the MethodWrapper on these. Could be > a package wide install/uninstall if you need that. > > > This would be a nice useless for Reflectivityâ¦ one way of describing it > is âlike method wrappers, but generalizedâ. e.g. you can put a âwrapperâ on > any kind of AST node. > After the breakpoints, we could use that as the next client. > yes Nick's Reflectogram would also be usable for that but it would require a special VM currently. Indeed, it would be better to have at the compiler level. Then, Ghost is also usable for that since Mariano did a MethodWrapper like implementation using Ghost in 5 lines or so. And Ghost should load in Pharo 3 ;-) Luc > > > > Marcus > > Norbert > > Am 04.11.2014 um 07:03 schrieb "phil(a)highoctane.be" <phil(a)highoctane.be>: > > > Le 3 nov. 2014 22:13, "Hilaire" <hilaire(a)drgeo.eu> a Ã©crit : > > > > What's wrong with? > > > > myData > > ^ data ifNil: [data := self computeMe] > > That I do have a lot of places like this and do not want these data > littering the code. > > Aspects would solve this but we do not have that. > > Also I need the mechanism to be removable. > > So, I read something about MethodWrapper, ghost, slots... Can't one use > any of these things to do this memoization cleanly? > > Phil > > > > > > > > > Le 03/11/2014 16:10, phil(a)highoctane.be a Ã©crit : > > > How can I do memoization in Pharo? > > > > > > I mean, a generic mechanism that will help me wrap the caching around > > > the method invocations / messages. > > > > > > I have expensive calls that do not have to refresh their results as > > > often as they are called. > > > > > > TIA > > > Phil > > > > > > -- > > Dr. Geo - http://drgeo.eu > > iStoa - http://istoa.drgeo.eu > > > > > > > > >

Nov. 4, 2014

Re: [Pharo-users] Memoization Question

by Norbert Hartl

> Am 04.11.2014 um 13:16 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > >> On 04 Nov 2014, at 09:59, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >> Ghost won't be a big help here. Slots would be a good solution but not if it needs to be removable on runtime. So it seems MethodWrappers is your best bet. I'd try create a caching MethodWrapper, mark all the needed methods with a pragma and then install the MethodWrapper on these. Could be a package wide install/uninstall if you need that. >> > > This would be a nice useless for Reflectivityâ¦ one way of describing it is âlike method wrappers, but generalizedâ. e.g. you can put a âwrapperâ on any kind of AST node. > After the breakpoints, we could use that as the next client. > > Sure, I forgot. If I would have the need to implement it I would try solving it with meta-links. Basically it does the same as the method wrapper without having the need to exchange the compiled method. Norbert > > Marcus > >> Norbert >> >> Am 04.11.2014 um 07:03 schrieb "phil(a)highoctane.be <mailto:phil@highoctane.be>" <phil(a)highoctane.be <mailto:phil@highoctane.be>>: >> >>> >>> Le 3 nov. 2014 22:13, "Hilaire" <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu>> a Ã©crit : >>> > >>> > What's wrong with? >>> > >>> > myData >>> > ^ data ifNil: [data := self computeMe] >>> >>> That I do have a lot of places like this and do not want these data littering the code. >>> >>> Aspects would solve this but we do not have that. >>> >>> Also I need the mechanism to be removable. >>> >>> So, I read something about MethodWrapper, ghost, slots... Can't one use any of these things to do this memoization cleanly? >>> >>> Phil >>> >>> > >>> > >>> > >>> > Le 03/11/2014 16:10, phil(a)highoctane.be <mailto:phil@highoctane.be> a Ã©crit : >>> > > How can I do memoization in Pharo? >>> > > >>> > > I mean, a generic mechanism that will help me wrap the caching around >>> > > the method invocations / messages. >>> > > >>> > > I have expensive calls that do not have to refresh their results as >>> > > often as they are called. >>> > > >>> > > TIA >>> > > Phil >>> > >>> > >>> > -- >>> > Dr. Geo - http://drgeo.eu <http://drgeo.eu/> >>> > iStoa - http://istoa.drgeo.eu <http://istoa.drgeo.eu/> >>> > >>> > >>> > >

Nov. 4, 2014

Re: [Pharo-users] Memoization Question

by Marcus Denker

> On 04 Nov 2014, at 09:59, Norbert Hartl <norbert(a)hartl.name> wrote: > > Ghost won't be a big help here. Slots would be a good solution but not if it needs to be removable on runtime. So it seems MethodWrappers is your best bet. I'd try create a caching MethodWrapper, mark all the needed methods with a pragma and then install the MethodWrapper on these. Could be a package wide install/uninstall if you need that. > This would be a nice useless for Reflectivityâ¦ one way of describing it is âlike method wrappers, but generalizedâ. e.g. you can put a âwrapperâ on any kind of AST node. After the breakpoints, we could use that as the next client. Marcus > Norbert > > Am 04.11.2014 um 07:03 schrieb "phil(a)highoctane.be <mailto:phil@highoctane.be>" <phil(a)highoctane.be <mailto:phil@highoctane.be>>: > >> >> Le 3 nov. 2014 22:13, "Hilaire" <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu>> a Ã©crit : >> > >> > What's wrong with? >> > >> > myData >> > ^ data ifNil: [data := self computeMe] >> >> That I do have a lot of places like this and do not want these data littering the code. >> >> Aspects would solve this but we do not have that. >> >> Also I need the mechanism to be removable. >> >> So, I read something about MethodWrapper, ghost, slots... Can't one use any of these things to do this memoization cleanly? >> >> Phil >> >> > >> > >> > >> > Le 03/11/2014 16:10, phil(a)highoctane.be <mailto:phil@highoctane.be> a Ã©crit : >> > > How can I do memoization in Pharo? >> > > >> > > I mean, a generic mechanism that will help me wrap the caching around >> > > the method invocations / messages. >> > > >> > > I have expensive calls that do not have to refresh their results as >> > > often as they are called. >> > > >> > > TIA >> > > Phil >> > >> > >> > -- >> > Dr. Geo - http://drgeo.eu <http://drgeo.eu/> >> > iStoa - http://istoa.drgeo.eu <http://istoa.drgeo.eu/> >> > >> > >> >

Nov. 4, 2014

Re: [Pharo-users] Memoization Question

by phil＠highoctane.be

On Tue, Nov 4, 2014 at 12:06 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I'm not sure. I thought Spy would use them but it does not load in a fresh > pharo3 for me. Did you try > > http://www.squeaksource.com/ObjectsAsMethodsWrap/ > This one loads and tests are green once the "_"s are replaced with ":="s Thx for the pointer. I'll see how I can hook a TTLCache into this. Phil > > ? > > Norbert > > Am 04.11.2014 um 11:53 schrieb phil(a)highoctane.be: > > On Tue, Nov 4, 2014 at 9:59 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Ghost won't be a big help here. Slots would be a good solution but not if >> it needs to be removable on runtime. So it seems MethodWrappers is your >> best bet. I'd try create a caching MethodWrapper, mark all the needed >> methods with a pragma and then install the MethodWrapper on these. Could be >> a package wide install/uninstall if you need that. >> > > I loaded MethodWrappers in 3.0 as I saw in > http://forum.world.st/MethodWrappers-td3829576.html#a4601624 > > Gofer it > squeaksource: 'MethodWrappers'; > package: 'MethodWrappers4'; > load. > > It loads. > > But no test seems to be fine. > > > <image.png> > > What version should I be using? > > Phil > > >> Norbert >> >> Am 04.11.2014 um 07:03 schrieb "phil(a)highoctane.be" <phil(a)highoctane.be>: >> >> >> Le 3 nov. 2014 22:13, "Hilaire" <hilaire(a)drgeo.eu> a Ã©crit : >> > >> > What's wrong with? >> > >> > myData >> > ^ data ifNil: [data := self computeMe] >> >> That I do have a lot of places like this and do not want these data >> littering the code. >> >> Aspects would solve this but we do not have that. >> >> Also I need the mechanism to be removable. >> >> So, I read something about MethodWrapper, ghost, slots... Can't one use >> any of these things to do this memoization cleanly? >> >> Phil >> >> > >> > >> > >> > Le 03/11/2014 16:10, phil(a)highoctane.be a Ã©crit : >> > > How can I do memoization in Pharo? >> > > >> > > I mean, a generic mechanism that will help me wrap the caching around >> > > the method invocations / messages. >> > > >> > > I have expensive calls that do not have to refresh their results as >> > > often as they are called. >> > > >> > > TIA >> > > Phil >> > >> > >> > -- >> > Dr. Geo - http://drgeo.eu >> > iStoa - http://istoa.drgeo.eu >> > >> > >> > >> >> > >

Nov. 4, 2014