Re: [Pharo-users] About Zinc http components
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@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, itli...@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.
Re: [Pharo-users] Using a private git repository with Metacello
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 jul...@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
Re: [Pharo-users] Testing Traits?
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.cas...@gmail.com wrote: On Thu, Oct 9, 2014 at 2:17 PM, Tim Mackinnon tim@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
Re: [Pharo-users] About Zinc http components
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@gmail.com mailto:alf.mmm@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, itli...@schrievkrom.de mailto:itli...@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.
Re: [Pharo-users] Spur images
On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe s...@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
