- Pharo-users - lists.pharo.org

Re: [Pharo-users] About Zinc http components

by stepharo

It would be really interesting to get a binding for Pharo. Stef On 7/10/14 23:51, kilon alios wrote: > 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 > <mailto:alf.mmm.cat@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> > <mailto:alf.mmm.cat@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. 11, 2014

Re: [Pharo-users] About Zinc http components

by Alain Rastoul

Exactly, for this part it's all about bytes on a wire :) : just sending/receiving serialized objects over a stream socket: consumers will be pulling data from producers in a synchronous way. I could use a simple stream socket for that, but I want to wrap data in messages to keep control over that part and probably add buffering at some layers. There will be no method invocations, just some control/monitor process from outside. Never heard about Squeak ELib but very interesting, thank you Pierce! Regards, Alain Le 11/10/2014 03:21, Pierce Ng a Ã©crit : > Whether using Zinc's websockets or some C library wrapper, you are still > slinging serialized Smalltalk objects ie plain old bytes over the wire, no? > > I am guessing that RST provides synchronous remote method invocation. I recall > there was a remote messaging prototype/concept based on promises developed in > Squeak... ah, Squeak-Elib, here: http://wiki.squeak.org/squeak/6011. > > Is your current use case mostly synchronous or asynchronous? > > Pierce > > >

Oct. 11, 2014

Re: [Pharo-users] Error with Pillar

by Ben Coman

Alexandre Bergel wrote: > hi! > > I get many error like: > > ========================================================= > COMPILING Book > ========================================================= > Compiling PDF... > libpng warning: iCCP: known incorrect sRGB profile > libpng warning: iCCP: known incorrect sRGB profile > libpng warning: iCCP: known incorrect sRGB profile > Compiling PDF... > libpng warning: iCCP: known incorrect sRGB profile > libpng warning: iCCP: known incorrect sRGB profile > libpng warning: iCCP: known incorrect sRGB profile > > Any idea what this could be? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > http://tex.stackexchange.com/questions/125612/warning-pdflatex-libpng-warni… ?

Oct. 11, 2014

Re: [Pharo-users] About Zinc http components

by Pierce Ng

On Thu, Oct 09, 2014 at 11:38:47PM +0200, Alain Rastoul wrote: > but for now, I prefer simpler and cleaner way - like smalltalk - to > do just what I want - it's more a matter of taste). Whether using Zinc's websockets or some C library wrapper, you are still slinging serialized Smalltalk objects ie plain old bytes over the wire, no? I am guessing that RST provides synchronous remote method invocation. I recall there was a remote messaging prototype/concept based on promises developed in Squeak... ah, Squeak-Elib, here: http://wiki.squeak.org/squeak/6011. Is your current use case mostly synchronous or asynchronous? Pierce

Oct. 11, 2014

Re: [Pharo-users] About Zinc http components

by kilon alios

I am interested too, my project depends on streamsocket to send python commands from pharo to blender . So far I have not stressed it too much and it looks like it works fast enough. Maybe something like websockets or nanomsg is better for me in the long run so I too keep an eye on these solutions. Time will tell. On Fri, Oct 10, 2014 at 12:38 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 09/10/2014 14:14, kilon alios a Ã©crit : > >> I am almost always right. >> >> Good medicine :) > > maybe ask the original author/s via github ? Why do things the hard way ;) >> >> Yes may be I will after having looked closely at the source, > no hard way here, it's not a problem to read c or c++ code, > just a little pain (for me) to write some (I did a lot, and even liked it > long time ago, > but for now, I prefer simpler and cleaner way - like smalltalk - to do > just what I want - it's more a matter of taste). > If I use this library they won't debug my code. In smalltalk with > ZnWebSocket, I could easily, > in c or c++ I could too but a bit harder - I'll have to rebuild libraries, > use an external debugguer and so on - not a big deal > but I don't like it much. > > On Wed, Oct 8, 2014 at 8:54 AM, Alain Rastoul >> <alf.mmm.cat(a)gmail.com >> <mailto:alf.mmm.cat@gmail.com>> wrote: >> >> 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 >> <mailto:itlists@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. 10, 2014

Re: [Pharo-users] Error with Pillar

by stepharo

Probably the encodings of the figures. Stef On 10/10/14 14:39, Alexandre Bergel wrote: > hi! > > I get many error like: > > ========================================================= > COMPILING Book > ========================================================= > Compiling PDF... > libpng warning: iCCP: known incorrect sRGB profile > libpng warning: iCCP: known incorrect sRGB profile > libpng warning: iCCP: known incorrect sRGB profile > Compiling PDF... > libpng warning: iCCP: known incorrect sRGB profile > libpng warning: iCCP: known incorrect sRGB profile > libpng warning: iCCP: known incorrect sRGB profile > > Any idea what this could be? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

Oct. 10, 2014

Error with Pillar

by Alexandre Bergel

hi! I get many error like: ========================================================= COMPILING Book ========================================================= Compiling PDF... libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile Compiling PDF... libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile Any idea what this could be? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 10, 2014

Re: [Pharo-users] Spur images

by Benjamin Pollack

On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: [snip] > Apart from that, the tokenisation is not very efficient, #lines is a > copy of your whole contents, so is the #split: and #trimmed. The > algorithm sounds a bit lazy as well, writing it 'on purpose' with an eye > for performance might yield better results. So I was reflecting on this more. If String and WideString were immutable, then it'd be easy to avoid all of these copies; you could instead pass around very tiny objects that had only three members (a String, a start position, a stop position), and avoid copying very much data. It's that String and WideString are mutable that preclude that. For fun, since I know I won't mutate the stringsin this example, I actually did a quick spike where I replaced #copyFrom:to: with a new method I introduced called #viewFrom:to: that returned a StringView. I'll post the code when I have a chance to clean it up if there's interest, but it looks like it pretty handedly chops off 120-150ms from that runtime (i.e., double the speed). Has there been any thought to introducing some immutable collections? Or maybe I'm just missing them? They'd be useful not just for String and WideString, but really for basically any of the collection types. The implementation in most cases would be as simple as overriding #at:put: and friends to throw "self shouldNotImplement", and then providing methods/classes like the one I introduced to allow taking advantage of the newfound immutability. If there's interest, I'd be happy to submit a Slice we could use as a concrete RFC of what this could look like. --Benjamin

Oct. 10, 2014

Re: [Pharo-users] About Zinc http components

by Alain Rastoul

Le 09/10/2014 14:14, kilon alios a Ã©crit : > I am almost always right. > Good medicine :) > maybe ask the original author/s via github ? Why do things the hard way ;) > Yes may be I will after having looked closely at the source, no hard way here, it's not a problem to read c or c++ code, just a little pain (for me) to write some (I did a lot, and even liked it long time ago, but for now, I prefer simpler and cleaner way - like smalltalk - to do just what I want - it's more a matter of taste). If I use this library they won't debug my code. In smalltalk with ZnWebSocket, I could easily, in c or c++ I could too but a bit harder - I'll have to rebuild libraries, use an external debugguer and so on - not a big deal but I don't like it much. > On Wed, Oct 8, 2014 at 8:54 AM, Alain Rastoul > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> wrote: > > 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 > <mailto:itlists@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. 9, 2014

Re: [Pharo-users] Testing Traits?

by Tim Mackinnon

Thanks Damien - Iâll load up Nile and see what you guys did. I figured it might be the case that you have to create a TestTrait - although it does feel a bit like creating a TestConcreteClass to test an AbstractClass, which also feels a bit strange - and caused me (probably rightly so), to avoid inheritance and prefer delegation/composition. Maybe its not so bad to have a TestTrait in practice - but I still wonder if there is a neat trick where it would be handy to âinstantiateâ one in test mode, where you specify a fake dependency and use that to right tests. Anyway - Iâll learn to crawl before trying to run ;) Tim On 9 Oct 2014, at 14:05, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Thu, Oct 9, 2014 at 2:17 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> Any thoughts/pointers? > > I would tend to create one test trait for each application trait the > same way I create one test class for each application class. That > exactly what I did with the Nile stream trait-based library (there is > a journal paper about this library but I don't remember if it covers > the unit-test). The source code is available at > http://www.squeaksource.com/Nile.html. > > You can look at the unit tests for the collection library that are > entirely based on traits (but the collection library itself is not). > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Oct. 9, 2014