- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by Camillo Bruni

On 2012-11-08, at 04:39, Igor Stasenko <siguctua(a)gmail.com> wrote: > sure sure.. > but guys... i really doubt that i would want to see people poking with > NB who don't even have a > basic understanding of malloc(ed) memory management and working with > memory buffers & pointers. > For such sort of people, best what i can offer is "go back when you > will learn basics first". that reads for me: everybody but me should use it. And you can be pretty sure that most pharoers (including myself) have a pretty vague notion about malloc/free, combined with the internals of an third party C library, that makes a pretty unstable field. Again, no silver bullets here, but less arrogance and more examples! > Of course, it would be cool if NB could work even for "dummies", but i > am thinking , as any technology, > before you start using it without shooting yourself into foot, you > should do some homework first.

Nov. 8, 2012

Re: [Pharo-project] Tips for efficient multi-serial handling

by drush66

Hi Udo! Well, as fare as I know there is currently no equivalent Ruby's EventMachine, or similar event based server infrastructure. There is AioPlugin for async IO http://wiki.squeak.org/squeak/3384 which lets Smalltalk process (looking from the os view) to get async notifications of IO events, and signal semaphore which could then be used to activate sleeping smalltalk process (now I talk about process from the smalltalk VM view). This is useful but I think it does not address all of 10ck issues effectively. Also: - I am not sure it works on windows - I am not sure it can be used for serial ports In the long run I always wanted to take a stab into something like EventMachine for Pharo, at least for the basic tcp protocol, but never got the time. Also Delivering all important protocols on top of it (like HTTP, SMTP, AMQP, file io, serial, etc, etc) would probably be huge undertaking since most existing libraries would need considerable amount of love to be used in evented manner, some maybe even complete new event based versions. ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Tips-for-efficient-multi-serial-handling-tp4653104p46… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 8, 2012

Re: [Pharo-project] Tips for efficient multi-serial handling

by Udo Schneider

Hi Igor, thanks for the reply. The idea working with Semaphore has definitly it's own charm. From my last (high-level) check I only found serial primitives which return 0 bytes if nothing was recieved meanwhile - no Semaphore as far as I saw. Regarding adding support for this - I try to stay away from the VM (due to C - no pun intended!) as far as possible. So I'd rather pay somebody who knows his was around in the VM to do it :-) Volunteers? Best Regards, Udo On 08.11.12 05:13, Igor Stasenko wrote: > Sorry, Udo, for quick response. > > I think you can do that with Pharo without polling. You just use > semaphores (which directly signaled by OS+VM). > I am not sure about if everything in VM (usb/midi /etc) uses > non-blocking i/o out of the box, > but if you really really want to hake it and ready to pay for it (in > terms of own time (or somebody else's ;) )) > i do not see any impenetrable barriers there. > >

Nov. 8, 2012

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by Max Leske

I get your point Igor but then again, we're all somewhat self taught which means that as a developer if you don't understand something you hack around until you get it. It's not like I'm going to break anything in the released products, right? And I think I can judge the risk of wrecking my own machine. I think that helping each other out on this list is more important than scowling at the noobs and yelling "DON'T TOUCH". Sorry if that comes across harsh but I'm honestly a little upset. Max On 08.11.2012, at 04:39, Igor Stasenko <siguctua(a)gmail.com> wrote: > sure sure.. > but guys... i really doubt that i would want to see people poking with > NB who don't even have a > basic understanding of malloc(ed) memory management and working with > memory buffers & pointers. > For such sort of people, best what i can offer is "go back when you > will learn basics first". > > Of course, it would be cool if NB could work even for "dummies", but i > am thinking , as any technology, > before you start using it without shooting yourself into foot, you > should do some homework first. > > > On 7 November 2012 08:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> + 1 >> >> On Nov 7, 2012, at 9:43 AM, Camillo Bruni wrote: >> >>> Just copy paste the thing you posted in the NBBasicExamples and we're >>> done. A couple of examples which show common problems will help >>> certainly help people to understand. >>> >>> Plus we should convert the examples into tests so they are always run! >>> >>> On 2012-11-07, at 09:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>> On Nov 6, 2012, at 11:06 PM, Igor Stasenko wrote: >>>> >>>>> On 6 November 2012 17:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>> This is clearly something to add to the documentation of NativeBoost. >>>>>> Igor can you do it? >>>>> >>>>> I already have a description of memory management API for NB in docs. >>>>> And telling how manage external memory is... ahem.. not really fits into docs :) >>>>> Maybe a tutor or something. >>>> >>>> think not technical but user! >>>> Id o not give a shit if what helps me is called a doc or a tutorial. >>>> I care that it helps me fixing my problem. >>>> And what I see is that the example of Max is a nice example of a recurring problem >>>> people face. >>>> >>>> Stef >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Nov. 8, 2012

Re: [Pharo-project] Tips for efficient multi-serial handling

by Igor Stasenko

Sorry, Udo, for quick response. I think you can do that with Pharo without polling. You just use semaphores (which directly signaled by OS+VM). I am not sure about if everything in VM (usb/midi /etc) uses non-blocking i/o out of the box, but if you really really want to hake it and ready to pay for it (in terms of own time (or somebody else's ;) )) i do not see any impenetrable barriers there. -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] Cheating NB FFI ByteArray size

by Igor Stasenko

On 7 November 2012 11:09, Camillo Bruni <camillobruni(a)gmail.com> wrote: > just never forget that we have a moving GC! ;) so directly passing references > to native function can be quite dangerous! > i hope LZ4 written in a good way, which doesn't requires you to keep a valid pointer to a buffer once it return(s) from LZ4 function. > Otherwise you could first manually adjust the start address by writing > the corresponding ASM code ;) then run the C callout. I should check if > we already have a proper helper method for that. > @Mariano, i described the trick how you can do that in another reply. This is trivial to do with ASM code, the non-trivial part is how to "formally" express that in callout .. which will turn it from being "cheat" into "feature" :) Of course, if that actually necessary at all. IMO, cheat is fine. > > On 2012-11-07, at 14:33, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi Igor. I wonder if I can do the following. >> I have to pass a ByteArray to a function that expects an already malloced >> char*. >> So far it is working fine. Now...what I would like is from the image side >> to allocate a ByteArray of size + 4. I need to reserve the first 4 bytes of >> the ByteArray for something. But the library I am calling doesn't let me >> specify where to start from that char*. >> So...can I cheat? I mean, can I allocate ByteArray+4 in the image, but when >> passing it as an argument somehow say "ok, take this ByteArray but think >> the the beginning is the byte 4" ? >> or something like that ? >> >> Thanks! >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] Pharo 2.0 and Metacello preview

by Igor Stasenko

On 7 November 2012 06:22, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Igor. Not everything is easy in this life ;) "only about including > osprocess to image" is actually quite hard. OSProcess uses FileDirectory a > lot. During the last sprint, Francois and me where trying to make oSProcess > to work in 2.0. We spent the whole afternoon and it is yet not fully > working. > did i said that it would be easy? :) It is not me who said that OSProcess should be there by default. I saying it now, because i also came to same conclusion (maybe later than others). I wish i could help with that somehow (like convincing Camillo to take a look at it instead of working on PhD ;) -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by Igor Stasenko

sure sure.. but guys... i really doubt that i would want to see people poking with NB who don't even have a basic understanding of malloc(ed) memory management and working with memory buffers & pointers. For such sort of people, best what i can offer is "go back when you will learn basics first". Of course, it would be cool if NB could work even for "dummies", but i am thinking , as any technology, before you start using it without shooting yourself into foot, you should do some homework first. On 7 November 2012 08:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > + 1 > > On Nov 7, 2012, at 9:43 AM, Camillo Bruni wrote: > >> Just copy paste the thing you posted in the NBBasicExamples and we're >> done. A couple of examples which show common problems will help >> certainly help people to understand. >> >> Plus we should convert the examples into tests so they are always run! >> >> On 2012-11-07, at 09:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> >>> On Nov 6, 2012, at 11:06 PM, Igor Stasenko wrote: >>> >>>> On 6 November 2012 17:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> This is clearly something to add to the documentation of NativeBoost. >>>>> Igor can you do it? >>>> >>>> I already have a description of memory management API for NB in docs. >>>> And telling how manage external memory is... ahem.. not really fits into docs :) >>>> Maybe a tutor or something. >>> >>> think not technical but user! >>> Id o not give a shit if what helps me is called a doc or a tutorial. >>> I care that it helps me fixing my problem. >>> And what I see is that the example of Max is a nice example of a recurring problem >>> people face. >>> >>> Stef >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> > > -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] NB integration

by Igor Stasenko

On 2 November 2012 10:07, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > pharo 2.0 will be "athens ready"... that means NB ready too :) > well, i actually thought that we ship "athens-ready" VMs first.. But as long as we want to put an Athens preview into image.. that will also mean having NB loaded into image. (hearing chords of 'unnecessary bloating base image size' from afar) :) eh.. everything has its cost. > On Nov 2, 2012, at 2:00 PM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > > > you got my vote if it is easy enough to do ;) > > ________________________________ > From: Torsten Bergmann <astares(a)gmx.de> > To: pharo-project(a)lists.gforge.inria.fr > Sent: Friday, 2 November 2012, 12:15 > Subject: [Pharo-project] NB integration > > AFAIK there was a plan to integrate NativeBoost > into Pharo. Is it for 2.0 or 2.1? > > I would like to see it for 2.0... > > Thx > T. > > > > -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] Replace ByteArray with a smaller one

by Igor Stasenko

On 7 November 2012 11:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: > if the chunks you wan to cut off are big enough you could > potentially allocate a new object there which get's gc-ed. > yes.. actually you can 'crop' the existing object by modifying its size field (so VM will know it) and then for the rest bytes, mark them as a 'free chunk', which designates a unused memory space in heap. actually, this could be a good candidate for a primitive. But imo, much better strategy is to not allocate too big arrays. :) Also, as alternative , you can create a 'ArraySlice' collection class, which is a view on existing array but with smaller number or elements. And pass it around as a valid collection. > But I have no clue how to do that without VM / NB support ;) > > > On 2012-11-07, at 14:39, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi guys. I have a ByteArray of size N. >> And I want now only the same ByteArray but from 1 to N-X. I am using >> #copyFrom:to: but that one answers a new copy. If the ByteArray is large, >> this takes time because it needs to allocate a large object. In my case I >> don't care and I can modify the original ByteArray itself (lets say make it >> smaller, null the remaining part and change the object header info). That >> way I would avoid an extra allocation. Is there a primitive for that? >> >> Thanks! >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko.

Nov. 8, 2012