October 2014 - Pharo-users - lists.pharo.org

inaccuracy in drawing?

by Hilaire

Hello, I have noted inaccuracy when drawing circle (seen screenshot with circle and tangent line intersecting circle in two points and not one). I looked at my code with possible rounding error related to a mix of float and integer, I pay attention to convert to float when needed, but I can't fix the situation. Can it be related to Athens ? Is it ok to feed Athens with float numbers ? Thanks Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 8, 2014

Re: [Pharo-users] #quitSession

by Hilaire

Le 08/10/2014 10:30, Guillermo Polito a Ã©crit : > I'd say nobody used it before and that's why it is like it is :). Just > old unused code. Now I use it as it is now, at least I don't have to override system method to trap the quit session > > > I guess we can get something cleaner > with Announcement > > > Sure! I should take a look Thanks Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 8, 2014

Using a private git repository with Metacello

by Julien Delplanque

Hello, Is it possible to use Metacello to load a Pharo project from a private git repository hosted on bitbucket for example? If it is, how? To load project from github I use: Metacello new baseline: 'Project'; repository: 'github://owner/reponame/repository'; load. Is there a prefix for a git repository that is not hosted on github? Also, I think Metacello use HTTP to download the project, am I right? Is it possible to make it use ssh? Thanks in advance, Julien

Oct. 8, 2014

Re: [Pharo-users] #quitSession

by Guillermo Polito

On Wed, Oct 8, 2014 at 10:26 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > > > ifNotNil: [^self windowEventHandler windowEvent: anEvent]. > > Just a remark > Looking at this code and the protocol, self windowEventHandler must > responds a Morph. There are no such things as a WindowEventHandler in > the image. A bit misleading. > This whole implementation smell. I'd say nobody used it before and that's why it is like it is :). Just old unused code. > I guess we can get something cleaner > with Announcement > Sure! > > > Hilaire > > > Le 01/10/2014 13:51, Guillermo Polito a Ã©crit : > > I'd bet it is... > > > > PasteUpMorph>>windowEvent: anEvent > > self windowEventHandler > > ifNotNil: [^self windowEventHandler windowEvent: anEvent]. > > > > anEvent type == #windowClose > > ifTrue: [WorldState quitSession]. > > > > and #windowsEvent: is called in a sequence like: > > > > VM event => InputEventFetcher => Morphic event => PasteUpMorph ... > > > > On Wed, Oct 1, 2014 at 1:48 PM, Hilaire <hilaire(a)drgeo.eu > > <mailto:hilaire@drgeo.eu>> wrote: > > > > Hello, > > > > I would like to change the behavior of Pharo when the user clicks on > the > > close button of the host window. > > > > So far it looks like #quitSession is sended from somewhere, but I > fail > > to see the chain of call between the host window and the #quitSession > > message. > > > > Any idea? > > > > Thanks > > > > Hilaire > > > > > > -- > > Dr. Geo - http://drgeo.eu > > iStoa - http://istoa.drgeo.eu > > > > > > > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > >

Oct. 8, 2014

Re: [Pharo-users] #quitSession

by Hilaire

> ifNotNil: [^self windowEventHandler windowEvent: anEvent]. Just a remark Looking at this code and the protocol, self windowEventHandler must responds a Morph. There are no such things as a WindowEventHandler in the image. A bit misleading. This whole implementation smell. I guess we can get something cleaner with Announcement Hilaire Le 01/10/2014 13:51, Guillermo Polito a Ã©crit : > I'd bet it is... > > PasteUpMorph>>windowEvent: anEvent > self windowEventHandler > ifNotNil: [^self windowEventHandler windowEvent: anEvent]. > > anEvent type == #windowClose > ifTrue: [WorldState quitSession]. > > and #windowsEvent: is called in a sequence like: > > VM event => InputEventFetcher => Morphic event => PasteUpMorph ... > > On Wed, Oct 1, 2014 at 1:48 PM, Hilaire <hilaire(a)drgeo.eu > <mailto:hilaire@drgeo.eu>> wrote: > > Hello, > > I would like to change the behavior of Pharo when the user clicks on the > close button of the host window. > > So far it looks like #quitSession is sended from somewhere, but I fail > to see the chain of call between the host window and the #quitSession > message. > > Any idea? > > Thanks > > Hilaire > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > > -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 8, 2014

Re: [Pharo-users] About Zinc http components

by Alain Rastoul

You are both right. Question about nanomsg is the thread model (a big bonus of 0mq), which is not clear to me. they state: "...In nanomsg the objects are not tightly bound to particular threads and thus these problems don't exist...", about some thread related issues in 0mq. I'll have to check (with sources or more docs readings) if they are bound to an external thread. If they account for an external thread support, this is not possible with the current vm without writing some external C code (I could but I would not like). Le 08/10/2014 07:07, itlists(a)schrievkrom.de a Ã©crit : > 0MQ is defined by its exported C interface ... > > > Am 07.10.2014 um 23:51 schrieb kilon alios: >> nope but it is made (unlike 0mq which is made in C++) in C so its >> should be relative simple to wrap with NB or even TalkFFI. At least the >> parts that interest you. >> > > >

Oct. 8, 2014

Re: [Pharo-users] About Zinc http components

by itlists＠schrievkrom.de

0MQ is defined by its exported C interface ... Am 07.10.2014 um 23:51 schrieb kilon alios: > nope but it is made (unlike 0mq which is made in C++) in C so its > should be relative simple to wrap with NB or even TalkFFI. At least the > parts that interest you. > -- Marten Feldtmann

Oct. 8, 2014

Re: [Pharo-users] About Zinc http components

by Denis Kudriashov

I was try it many years ago with squeak. It was work great. I am sure it should be not difficult to adobt it for latest pharo 08 Ð¾ÐºÑ. 2014 Ð³. 1:09 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Alain Rastoul" <alf.mmm.cat(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > This is another subject and another functionality I will need too. > > The Rst link is of interest (thank you Denis) , I was thinking > of sending command objects with Fuel as all images will have the same > classes and performance is not very important here. > I was able to load RST in Pharo3, but did not made any test yet. > Does it works with Pharo ? > > @SKrish you are right, but I want to keep as simple as possible at the > beginning and tcpip should fit for a start. > > Cheers, > > Alain > > > Le 07/10/2014 21:40, S Krish a Ã©crit : > >> >> Typical issue in the EJB world : Remote Beans / Local Beans , though on >> inter process it was remote beans with its full stack RMI marshalling / >> unmarshalling. >> >> But can we not exploit shared memory and efficient Event mechanism to >> make the two process coordinate, that should be lot more efficient than >> TCP - IP / but if that performance suffices it would be fine.. >> >> >> >> >> On Tue, Oct 7, 2014 at 4:40 AM, Alain Rastoul >> <alf.mmm.cat(a)gmail.com >> <mailto:alf.mmm.cat@gmail.com>> wrote: >> >> Hi, >> I played a bit with ZnServer and other zinc components and have >> a question I can't answer myself (googling a bit didn't help neither), >> and I'm seeking for advice: does it makes sense to use a >> ZnServer/ZnWebSocket >> as a mechanism to transfer data between two pharo processes - in my >> case 8k ByteArray blocks ? >> Or is it a total non sense ? is it reliable ? >> First tests looks good : 18k blocks / second (145 Mb/s) on a laptop >> core i5 2.6Ghz. >> >> All comments and suggestions welcome >> >> Thanks in advance, >> >> Alain >> >> >> >> > > >

Oct. 8, 2014

Re: [Pharo-users] About Zinc http components

by kilon alios

nope but it is made (unlike 0mq which is made in C++) in C so its should be relative simple to wrap with NB or even TalkFFI. At least the parts that interest you. On Tue, Oct 7, 2014 at 11:56 PM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Nanosg looks interesting too, thank you Kilon, I will look at it closer > too. > Do you known some working bindings with pharo ? > > Alain > Le 07/10/2014 21:12, kilon alios a Ã©crit : > >> there is nanomsg which is a rethinking on 0mq and from same developers, >> its MIT licensed --> http://nanomsg.org/index.html >> >> On Tue, Oct 7, 2014 at 9:12 PM, Alain Rastoul >> <alf.mmm.cat(a)gmail.com >> <mailto:alf.mmm.cat@gmail.com>> wrote: >> >> Thanks you for your answers. >> >> 0mq looks great, but released with LGPL licence, and I don't like >> that (I don't >> understand why there is also a GPL licence file in the distribution >> ? - clearly a *noway*), >> I prefer a full smalltalk implementation I can debug when things go >> wrong. >> I think latency and timing problems would be the same, no big >> difference in performance. >> BTW knowing about this library is cool and may be of some help (who >> knows), >> thank you Marten for the reference. >> >> I agree totally with you Sven about performance and standards. >> And I also agree with you about reusing someone else's work ... >> I don't like to reinvent the wheel, especially a good wheel when >> mine would be worst, >> I would if I were a wheel specialist - clearly not the case here. >> >> Much (if not all) of what I found on the web about WebSocket is >> about a browser/server connection >> and does not talk about use in a server/server connection, hence my >> question. >> But you answered it, and your answer is ok with my thoughts >> (plus using Zn components is a breeze) >> >> Thanks again >> >> regards, >> >> Alain >> Le 07/10/2014 18:26, Paul DeBruicker a Ã©crit : >> >> marten wrote >> >> There are some good C libraries out there, which are suitable >> to >> connect programs with each other: a good example is 0MQ. >> >> Marten >> >> -- >> Marten Feldtmann >> >> >> >> Hi Marten, >> >> >> Is your 0mq library posted somewhere and MIT licensed? >> >> Thanks >> >> Paul >> >> >> >> -- >> View this message in context: >> http://forum.world.st/About-__Zinc-http-components-__ >> tp4783071p4783223.html >> <http://forum.world.st/About-Zinc-http-components- >> tp4783071p4783223.html> >> Sent from the Pharo Smalltalk Users mailing list archive at >> Nabble.com. >> >> >> >> >> >> >> > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Alain Rastoul

This is another subject and another functionality I will need too. The Rst link is of interest (thank you Denis) , I was thinking of sending command objects with Fuel as all images will have the same classes and performance is not very important here. I was able to load RST in Pharo3, but did not made any test yet. Does it works with Pharo ? @SKrish you are right, but I want to keep as simple as possible at the beginning and tcpip should fit for a start. Cheers, Alain Le 07/10/2014 21:40, S Krish a Ã©crit : > > Typical issue in the EJB world : Remote Beans / Local Beans , though on > inter process it was remote beans with its full stack RMI marshalling / > unmarshalling. > > But can we not exploit shared memory and efficient Event mechanism to > make the two process coordinate, that should be lot more efficient than > TCP - IP / but if that performance suffices it would be fine.. > > > > > On Tue, Oct 7, 2014 at 4:40 AM, Alain Rastoul > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> wrote: > > Hi, > I played a bit with ZnServer and other zinc components and have > a question I can't answer myself (googling a bit didn't help neither), > and I'm seeking for advice: does it makes sense to use a > ZnServer/ZnWebSocket > as a mechanism to transfer data between two pharo processes - in my > case 8k ByteArray blocks ? > Or is it a total non sense ? is it reliable ? > First tests looks good : 18k blocks / second (145 Mb/s) on a laptop > core i5 2.6Ghz. > > All comments and suggestions welcome > > Thanks in advance, > > Alain > > >

Oct. 7, 2014