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

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

Re: [Pharo-users] Using a private git repository with Metacello

by Dale Henrichs

Julien, I recently added bitbucket:// support to metacello[1]. If you follow the installation instructions here[2], you can get the support loaded into Pharo3.0. Dale [1] https://groups.google.com/forum/#!topic/metacello/0vOzvQL10cQ [2] https://github.com/dalehenrich/metacello-work#pharo30 On Wed, Oct 8, 2014 at 1:44 AM, Julien Delplanque <julien(a)tamere.eu> wrote: > 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. 9, 2014

Re: [Pharo-users] Testing Traits?

by Damien Cassou

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

Testing Traits?

by Tim Mackinnon

Iâve sort of padded around the edges of Traits, and decided to reread the papers and better understand them. One thing that occurs to me - if you want to test your traits, is the only suggested mechanism to test them in-situ with the classes that use them OR can you poof one up and test it by explicitly pumping in something that would represent âselfâ in its usage? Or is this the wrong question - and would you view Traits as a refactoring exercise - so you write tests for a concrete class first - and then extract them into a Trait keeping the tests running? This has the thorny side effect - which like inheritance, means that ultimately you have to test a BaseClass with all its concrete subclasses (so do you have to do the same with traits? As you may have overridden something you didnât intend?). I thought maybe the paper - âReusing and Composing Tests with Traitsâ might discuss this angle, but it doesnât cover it. Any thoughts/pointers? Tim

Oct. 9, 2014

Re: [Pharo-users] About Zinc http components

by kilon alios

I am almost always right. maybe ask the original author/s via github ? Why do things the hard way ;) On Wed, Oct 8, 2014 at 8:54 AM, Alain Rastoul <alf.mmm.cat(a)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 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