- Pharo-dev - lists.pharo.org

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Levente Uzonyi

On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one. My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory. And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around. Here is an example for a blocking connection without a timeout: Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork. > > ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs. ConnectionQueue is just a high level API, you can always use _Sockets_. Levente > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Wednesday, September 22, 2010 11:51 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote: > >> Levente, >> >> Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible. > > If the UI Process is using the Socket and it's using a blocking connection > method, then - no surprise - it will be blocked. This won't affect other > processes. > > If you were right, the following would block the UI Process for 100 > seconds, but it doesn't block it at all, just try it: > > Transcript open. > [ 10 timesRepeat: [ > | s | > [ > s := Socket new. > s connectNonBlockingTo: #[172 16 0 1] port: 12345. > s > waitForConnectionFor: 10 > ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. > s isConnected ifTrue: [ > Transcript show: 'Connected.'; cr. ]. > s close ] ensure: [ > s ifNotNil: [ s destroy ] ] ] ] fork. > > > What do you mean by "servers"? ConnectionQueue? > > > Levente > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Wednesday, September 22, 2010 9:55 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> the one running the gui >> >> In that case, you're wrong. The UI Process will be able to run, because >> other processes using Sockets will wait on Semaphores and not because of >> "time limits". So I just convinced myself (and hopefully you too) about >> that using Socket instances will not hang the entire image, just the >> Process that uses the Socket. Therefore the SocketPlugin is as good as >> possible. >> >> >> Levente >> >>> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Monday, September 20, 2010 10:14 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. >>> >>> Where? In the Socket class? And what's the "main thread"? >>> >>> >>> Levente >>> >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>> Sent: Monday, September 20, 2010 8:13 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>> >>>>> Levente, >>>>> >>>>> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. >>>> >>>> I guess you're using Socket>>#connectTo:port: which uses >>>> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >>>> the default timeout, use #connectTo:port:waitForConnectionFor: or >>>> implement your own low level method which waits on semaphore until it's >>>> signaled. If you want to terminate the connection attempt, just signal the >>>> semaphore yourself, like here: >>>> >>>> s := Socket newTCP. >>>> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." >>>> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." >>>> s semaphore waitTimeoutMSecs: 1000. >>>> s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." >>>> >>>> And for ConnectionQueue, simply don't use it if you don't like it. It >>>> doesn't have to poll at all, AFAIK it's just implemented that way. >>>> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >>>> don't block the image at all. But correct me if I'm wrong. >>>> >>>> >>>> Levente >>>> >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>>> Sent: Monday, September 20, 2010 7:01 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>> >>>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>>> >>>>>> Guillermo, >>>>>> >>>>>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >>>>> >>>>> When does a Socket block the image? >>>>> >>>>> >>>>> Levente >>>>> >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>>> >>>>>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>>>>> >>>>>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>>>>> >>>>>> Guille >>>>>> >>>>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>>>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>>>>> >>>>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>>>> where you can add any properties to object >>>>>> on the fly, without need of adding a methods or declaring additional >>>>>> instance variable in class... >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>>>> >>>>>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>>>>> hi guys >>>>>>>> >>>>>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>>>>> So we should really have a way to specify silent ui action. >>>>>>>> Does anybody have an idea how I could do that? >>>>>>>> >>>>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>>>>> >>>>>>> >>>>>>> use morph propertyAt: #borderStyle >>>>>>> so you don't have to break your head with it :) >>>>>>> >>>>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>>>> them even don't using any >>>>>>> kind of borders. That's makes me wonder if anything like color, border >>>>>>> style etc should belong to root classes >>>>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>>>> properties (which is currently sits in morphic >>>>>>> extensions are more appropriate storage for them). The only problem is >>>>>>> that accessing them is much slower than ivars. >>>>>>> >>>>>>>> Stef >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Schwab,Wilhelm K

Slightly overbuilt or not, we can bang out the details over time. The point is that Sig is bringing things into the image where it can be seen and changed vs. locked away in a compiled binary that often does not describe where/how it gets into trouble. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Thursday, September 23, 2010 11:30 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray) On 23 September 2010 18:21, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 September 2010 18:02, Igor Stasenko <siguctua(a)gmail.com> wrote: >> 2010/9/23 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>> >>> On Sep 23, 2010, at 4:03 07PM, StÃ©phane Ducasse wrote: >>> >>> igor >>> >>> May be a layer for people that are not fluent with assembly would help. >>> Make the path easy from FFI writing. >>> >>> It is already, RTM :) >>> http://code.google.com/p/nativeboost/wiki/NBFnSpecParser >>> >>> Get some patterns so that people can learn by following patterns. >>> >> >> Oh, yeah.. see. I was showing an example how to implement own >> primitive using NativeBoost. >> >> Of course, an FFI API is there, and doing all the magic under the >> hood, so you dont have to know any assemler voodo: >> >> releaseDC: hdc >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> >> ^ NBFFICallout stdcall: #( >> >> int ReleaseDC ( >> HWND self , " handle to window" >> HDC hdc " handle to DC " >> )) >> module: #user32 >> >> the above is an FFI call to external function ReleaseDC, which can be >> found in 'user32.dll' windoze module. >> > > One of Bill's concerns is to be able to customize an external library > search algorithm. > And i can easily extend this api for custom-loading a library: > > Suppose, that if you passing a block into #module: argument, instead > of string/symbol, > then this block should answer a ready-to-use external library handle. > So, then above example can be rewritten as: > > releaseDC: hdc > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^ NBFFICallout stdcall: #( > > int ReleaseDC ( > HWND self , " handle to window" > HDC hdc " handle to DC " )) > module: [ self whereTheHeckMyModule ] > oh, that's a bit overengineering... come-on.. this is just a smalltalk code.. so it could be just: module: self whereTheHeckMyModule so, callout expects either a module name (then it using a default search algorithm), or a ready for use module handle, then it is up to you to supply it. > > And you are free to implement #whereTheHeckMyModule in any way you like :) > > >>> Stef >>> >>> Cheers, >>> Henry >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Schwab,Wilhelm K

NICE!!!!! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Thursday, September 23, 2010 11:21 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray) On 23 September 2010 18:02, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/9/23 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> >> On Sep 23, 2010, at 4:03 07PM, StÃ©phane Ducasse wrote: >> >> igor >> >> May be a layer for people that are not fluent with assembly would help. >> Make the path easy from FFI writing. >> >> It is already, RTM :) >> http://code.google.com/p/nativeboost/wiki/NBFnSpecParser >> >> Get some patterns so that people can learn by following patterns. >> > > Oh, yeah.. see. I was showing an example how to implement own > primitive using NativeBoost. > > Of course, an FFI API is there, and doing all the magic under the > hood, so you dont have to know any assemler voodo: > > releaseDC: hdc > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^ NBFFICallout stdcall: #( > > int ReleaseDC ( > HWND self , " handle to window" > HDC hdc " handle to DC " > )) > module: #user32 > > the above is an FFI call to external function ReleaseDC, which can be > found in 'user32.dll' windoze module. > One of Bill's concerns is to be able to customize an external library search algorithm. And i can easily extend this api for custom-loading a library: Suppose, that if you passing a block into #module: argument, instead of string/symbol, then this block should answer a ready-to-use external library handle. So, then above example can be rewritten as: releaseDC: hdc <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout stdcall: #( int ReleaseDC ( HWND self , " handle to window" HDC hdc " handle to DC " )) module: [ self whereTheHeckMyModule ] And you are free to implement #whereTheHeckMyModule in any way you like :) >> Stef >> >> Cheers, >> Henry >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Schwab,Wilhelm K

Sig, You say "Of course, an FFI API is there" but it's not always clear what is and isn't working. You appear to be further along that I thought was the case. I *really* enjoy being wrong in that direction :) And yes, being able to enter ASM is good - it would be REALLY bad if we had to do that for everything. Add some questions (valid or FUD, I don't know yet) about the ease of use of Alien, and it gets confusing. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Thursday, September 23, 2010 11:02 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray) 2010/9/23 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On Sep 23, 2010, at 4:03 07PM, StÃ©phane Ducasse wrote: > > igor > > May be a layer for people that are not fluent with assembly would help. > Make the path easy from FFI writing. > > It is already, RTM :) > http://code.google.com/p/nativeboost/wiki/NBFnSpecParser > > Get some patterns so that people can learn by following patterns. > Oh, yeah.. see. I was showing an example how to implement own primitive using NativeBoost. Of course, an FFI API is there, and doing all the magic under the hood, so you dont have to know any assemler voodo: releaseDC: hdc <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout stdcall: #( int ReleaseDC ( HWND self , " handle to window" HDC hdc " handle to DC " )) module: #user32 the above is an FFI call to external function ReleaseDC, which can be found in 'user32.dll' windoze module. > Stef > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Schwab,Wilhelm K

Sig, I certainly don't want to stir up a war you might be trying to avoid, but it does strike me that you offer an alternative to FFI. That's ok, because Alien clearly does that, so we might as well have a third choice. Please make a lot of noise when you have a Linux plugin. I will give some thought to what might make a useful project/demo, but OpenGL should certainly have its points in both directions. If it does something cool, so much the better. Long term, it would be nice to have a retained mode 3D system. Croquet's TObject hierarchy seemed to be heading in the right direction, but they resisted the idea of putting a 3D world in a 2D application; I'm thinking of 3D modeling, games, etc. A way to create a window, add some objects, lights and a camera and rotate, move them would be wonderful to have. Alice is/was close, but it required a lot of turning off Wonderland (end user) features that I felt should have been added if desired rather than taken away. It also required the mathematically aware to think like layman, which was a problem. Prior to finding QCad, I designed a few electronics enclosures by putting "boxes on shelves" and flying around it with the help of Alice. There is a grant application I need to be working on (should be doing so right now, in fact, right Stef?<g>). That has me thinking about Fourier Transforms, graphs and statistics. I have a fairly pathetic DOUBLEArray that seems to work. Having a complete set of double, float, [s]dword, [s]word arrays would be nice for many uses. When 1.1.1 comes along, I need to redo some FFI code to benefit from the selector fixes. I might be able to stall that long enough to try NB, but it really just needs to have some things renamed. My PLplot interface could be redone or not, but so far I see no reason to bother. If it ends up needing callbacks, it would be a good candidate. A different interface really needs work because it screams for callbacks and would be a wonderful showpiece for NB. That's a big job, but a good goal. There is little to no time pressure (what I have works as far as it goes), but a big payoff if I can make it work with callbacks. >From a marketing perspective, if you don't yet have a cool 3D demo, that might be your best use of time. Either way, I need to slowly study what you have and begin to experiement toward the above mentiond rewrite once you have Linux locked down. If you do have a cool 3D demo, why isn't it linked from your NativeBoost web site? :) Seriously, add a page of links to projects, or just one page that links to the SqueakSource pages of interest. The easier you make it for someone to see that you can do all of this stuff, the more likley you are to create converts. Have you looked at Ocean? It is being built with Alien. When you can do Windows, Linux and Mac, there might be an argument to switch. I don't control the project, but it seems reasonble to at least consider NB for it. I hope that's of some help. I look forward to trying it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Thursday, September 23, 2010 9:07 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray) On 23 September 2010 06:11, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > The examples that make sense depend on what NativeBoost wants to be when it grows up. Is it a full competitor to FFI and/or Alien? If so, then it would be nice to see a rich set of calls to functions with different parameter types; ideally it would be in the form of something useful that gets added to Pharo using NativeBoost. That does a couple of things, providing both proof of concept and examples in one shot. > One major 'proof of concept' kinda, is NBOpenGL package, which provides a full OpenGL bindings by using NativeBoost :) But sure thing, basic examples is a must. That's why i asked you , whant you wanna see. I have no idea, what can be userful to pharoers , since i can do anything and its completely trivial for me to implement, as an author of this project ;) So, without some feedback, i have no idea, if something in my code looks confusing, or hard to use and needs deeper explanation(s) and examples. > With tongue firmly in cheek, looking at your indexing example, my stack might pop before the machine's :) However, it looks like it should settle down quickly enough, and things like that go on in the vm all the time; you are arguably just brining it into the image. Indeed. Arguably. You putting your code into an image, instead of extra plugin. So, once your code is debugged and works well, you are done, and don't have to worry with shipping a custom VM/plugin with your product. The development and deployment of new primitives is much faster if you using NB. > Where would #readDoubleFrom: be in the class hiearchy? One of the reasons I asked about indexing an external array is that FFI is not good at such things. If you can provide ways to copy, fill, etc. blocks of memory and do it quickly, you gain ground, assuming you want to compete with FFI. In this particular example, you can do a usual way - make a DoubleArray class, which is a subclass of ByteArray , then implement #at: and #at:put: using nativeboost. Implement various stuff to fully cover Collection protocol, implement any extra stuff like blob operations (multiplication, addition etc) if you want. And you don't have to compete with FFI, since you can implement all primitives in NativeBoost without using any external functions. You can use any kind of optimizations in native code, which are not available in C, like using SSE/SIMD instructions etc. Even more, you can detect a CPU type, and depending on that, generate a most efficient code for your little class/library. > > Do callbacks, and you gain a lot of ground. Make calls on separate threads, and you gain a LOT of ground. That assumes that you can make it simple enough for a mildly above-average C programmer to understand how to use and ideally extend it. I will look at your example package on Squeak Source. Callbacks is there. See NBFFICallbackTests>>benchQSort for example. > > One thing that drives me nuts with the Linux vm is that it looks for things where it wants to look, and gives no feedback about what it tried to do or even that it failed (except that handle is still zero). Your callout pragmas take a module name; is there any way to see inside of that or to provide a full path to the library? It is nice to be able to confirm loading of a library w/o having to call something, since there won't always be something "safe" (free of side effects) to call as a test. > Wait, there is no callout pragmas.. All stuff which starts from ^ NBFFICallout cdecl: #( double ( void * address) ) ... is smalltalk code, and you can debug it and see what it does, and how it loading a module and retrieving an external function pointer from it. You can customize this procedure in any way you want (by subclassing NBFFICallout), you can even customize the way how you making a call. For instance, in NBOpenGL, a generated code does not making a direct call to previously discovered function address. It using an sub-instance of NBOpenGLAPIBase, which is a variable-sized object, holding a function pointers, and it reads a corresponding pointer from this object, and only then making a call. So, there are plenty various tricks which can be done without much hassle. You just need to step away from rigid patterns, imposed by C compler, linker and all stuff around that, and you will see, that you can do miracles in smalltalk + native code :) > At the risk of seeming difficult, everything is academic until we have a Linux plugin or at least can build same. Alien has that problem. I'm working on that. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, September 22, 2010 10:05 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] NativeBoost examples (was: Re: DoubleArray) > > On 23 September 2010 02:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> Fair enough :) The most recent thing I recall on NativeBoost is Stef asking for what I assume must be a Mac plugin; I thought Linux would be left out too, but it appears not, though it is not in my current vm. Beyond some list traffic, I found this: >> > > The work for supporting Linux and Mac is in progress. > >> http://code.google.com/p/nativeboost/wiki/NativeBoost >> >> Is there other documentation somewhere? Build instructions? > > You can find all existing documentation, installation instructions on > wiki pages at the above site. There is no other place for it. > http://code.google.com/p/nativeboost/wiki/Installation - installation > instructions. > >> You have a block copy, which is good. What about indexing, such as getting floats or doubles out of external memory? > > This is just a piece of cake. ;) > > readDoubleFrom: address > " This method loads the double from given external address. > an address can be an instance of NBExternalAddress, or > simple ByteArray with at least 8 bytes long, which holds a double > floating value" > > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > "We are using a pseudo-function prototype and supplying own assembler code, > instead of making a call to external function. > In given example, an address argument , after coercion is pushed on stack. " > > ^ NBFFICallout > > cdecl: #( double ( void * address) ) > " A pseudo-function takes 1 argument, and returns double value. > Under cdecl call convention, all floating point return types is > returned in fp(0) CPU register" > > emitCall: [:gen | | asm | > asm := gen asm. > > "Here , we expecting that an address value is already pushed on stack" > > asm pop: asm EAX; "load an address value into EAX register by > popping a stack" > fld: (asm EAX ptr64). "load a floating point value from memory, at > base address, held in EAX register into fp(0) register, > we are using #ptr64, to indicate that memory operand size is 64bits long" > > " return value set, we are done. A code generator will take care > for emitting code, which converts > a double floating point value into smalltalk object. " > ] > > I just uploaded this example and also how to write doubles from/to memory. > See at SqS/NativeBoost - NativeBoost-Examples package, class NBBasicExamples. > >> I am very comfortable adding functions to a library for integer and float/double calculations on "large" arrays and calling them via FFI; plugins are another story. Are there examples to follow? > > Tell me, what examples you would like to see. I will gladly provide them. > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Wednesday, September 22, 2010 6:20 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] DoubleArray >> >> On 23 September 2010 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Henry, >>> >>> I have been getting away with #doubleAt: and #doubleAt:put:, and otherwise doing pretty much what you said, though I just use a byte array to hold the data. It seems to work; for FFI, I end up passing void pointers instead of double pointers, which I don't like doing. >>> >>> Your point about using ordinary arrays makes sense to a point, though even w/o external interfacing, there is still a use for DoubleArray just as there is a use for String vs. an array of characters. >>> >> >> The main reason, why they are not here, that VM needs an additional >> set of primitives, which working with them. >> >> <sellsman hat on> >> I can only say that with NativeBoost, you could be able to implement >> it quite easily in image and ship it in image, >> without a need to change VM or use external plugin. >> <sellsman hat off> >> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] >>> Sent: Wednesday, September 22, 2010 5:23 PM >>> To: pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] DoubleArray >>> >>> On 22.09.2010 23:09, Schwab,Wilhelm K wrote: >>>> Squeak, deliberately, does not have a double array class. Is that because there is some horrible reason it can't work, or because it won't work on certain platforms? >>> If the goal is to pass it as a parameter to an external function, one >>> way would be to subclass WordArray, storing(and reading) each Float in >>> two elements, and have the endianness decided by Smalltalk endianness. >>> Probably want a startUp method for the class to swap instances >>> endianness if the platform has changed as well. >>>> Put another way, should we add such a class, if only via an external heap or whatever would be needed to make it reliable? >>>> >>>> Bill >>> More likely because no one has actually had a need for one. >>> It's definitely not _needed_ in base, where normal arrays of floats >>> would do the same job just as well, if not better. >>> IMHO, if someone makes one, it so should probably be part of a package >>> related to external interfacing. >>> >>> Cheers, >>> Henry >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Levente Uzonyi

On Thu, 23 Sep 2010, Hannes Hirzel wrote: >> >> Why can't we have stuff from Sophie back to Squeak/Pharo? >> - only the Sophie developers are familiar with the code and they are not >> motivated enough to extract it > > Not necessarily their task..... :-) That's right, but tell me who else is up to the task? > Writing libraries and reusable components is a different project. > >> - the license is BSD, so the code can't be included in Pharo/Squeak > > I googled for > BSD MIT license compatibility > > and found some interesting information > > see for example > http://www.dwheeler.com/essays/floss-license-slide.html > > the paragraph about BSD in > http://producingoss.com/en/license-choosing.html > > The license might be compatible depending on the "version" of the BSD > license. And if not you could extract code and then ask the developers > to release it as MIT. > > MIT and BSD are very close (or the same depending on the version) > > To summarize: The statement > > "the license is BSD, so the code can't be included in Pharo/Squeak" > > is too strong. There might be some problems including code, but they > may be solved easily with by writing a few emails.... The license is the 3-clause BSD license, it contains the following non-endorsement clause: "Neither the name of the University of Southern California, Los Angeles nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." I wonder what can be done about this. Levente > > > --Hannes > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Igor Stasenko

On 23 September 2010 18:21, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 September 2010 18:02, Igor Stasenko <siguctua(a)gmail.com> wrote: >> 2010/9/23 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>> >>> On Sep 23, 2010, at 4:03 07PM, StÃ©phane Ducasse wrote: >>> >>> igor >>> >>> May be a layer for people that are not fluent with assembly would help. >>> Make the path easy from FFI writing. >>> >>> It is already, RTM :) >>> http://code.google.com/p/nativeboost/wiki/NBFnSpecParser >>> >>> Get some patterns so that people can learn by following patterns. >>> >> >> Oh, yeah.. see. I was showing an example how to implement own >> primitive using NativeBoost. >> >> Of course, an FFI API is there, and doing all the magic under the >> hood, so you dont have to know any assemler voodo: >> >> releaseDC: hdc >> Â Â Â Â <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> >> Â Â Â Â ^ NBFFICallout stdcall: #( >> >> Â Â Â Â Â Â Â Â int ReleaseDC ( >> Â Â Â Â Â Â Â Â Â HWND self , Â " handle to window" >> Â Â Â Â Â Â Â Â Â HDC hdc Â Â " handle to DC " >> Â Â Â Â Â Â Â Â )) >> Â Â Â Â Â Â Â Â module: #user32 >> >> the above is an FFI call to external function ReleaseDC, which can be >> found in 'user32.dll' windoze module. >> > > One of Bill's concerns is to be able to customize an external library > search algorithm. > And i can easily extend this api for custom-loading a library: > > Suppose, that if you passing a block into #module: argument, instead > of string/symbol, > then this block should answer a ready-to-use external library handle. > So, then above example can be rewritten as: > > releaseDC: hdc > Â Â Â Â <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > Â Â Â Â ^ NBFFICallout stdcall: #( > > Â Â Â Â Â Â Â Â int ReleaseDC ( > Â Â Â Â Â Â Â Â Â HWND self , Â " handle to window" > Â Â Â Â Â Â Â Â Â HDC hdc Â Â " handle to DC " )) > Â Â Â Â Â Â Â Â module: [ self whereTheHeckMyModule ] > oh, that's a bit overengineering... come-on.. this is just a smalltalk code.. so it could be just: module: self whereTheHeckMyModule so, callout expects either a module name (then it using a default search algorithm), or a ready for use module handle, then it is up to you to supply it. > > And you are free to implement #whereTheHeckMyModule in any way you like :) > > >>> Stef >>> >>> Cheers, >>> Henry >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Igor Stasenko

On 23 September 2010 18:02, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/9/23 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> >> On Sep 23, 2010, at 4:03 07PM, StÃ©phane Ducasse wrote: >> >> igor >> >> May be a layer for people that are not fluent with assembly would help. >> Make the path easy from FFI writing. >> >> It is already, RTM :) >> http://code.google.com/p/nativeboost/wiki/NBFnSpecParser >> >> Get some patterns so that people can learn by following patterns. >> > > Oh, yeah.. see. I was showing an example how to implement own > primitive using NativeBoost. > > Of course, an FFI API is there, and doing all the magic under the > hood, so you dont have to know any assemler voodo: > > releaseDC: hdc > Â Â Â Â <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > Â Â Â Â ^ NBFFICallout stdcall: #( > > Â Â Â Â Â Â Â Â int ReleaseDC ( > Â Â Â Â Â Â Â Â Â HWND self , Â " handle to window" > Â Â Â Â Â Â Â Â Â HDC hdc Â Â " handle to DC " > Â Â Â Â Â Â Â Â )) > Â Â Â Â Â Â Â Â module: #user32 > > the above is an FFI call to external function ReleaseDC, which can be > found in 'user32.dll' windoze module. > One of Bill's concerns is to be able to customize an external library search algorithm. And i can easily extend this api for custom-loading a library: Suppose, that if you passing a block into #module: argument, instead of string/symbol, then this block should answer a ready-to-use external library handle. So, then above example can be rewritten as: releaseDC: hdc <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout stdcall: #( int ReleaseDC ( HWND self , " handle to window" HDC hdc " handle to DC " )) module: [ self whereTheHeckMyModule ] And you are free to implement #whereTheHeckMyModule in any way you like :) >> Stef >> >> Cheers, >> Henry >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2010

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?

by Alain Plantec

Le 23/09/2010 16:03, Henrik Johansen a Ã©crit : > Sounds like a plan, I feel the StrikeFont port from Cuis is new robust enough now to drop accuny completely. > Personally I find 7 a good size for tooltips/buttons, haven't used the even smaller sizes. > too small here, but of course, the 7 is available if we want to include it. > The package should be updated to provide proper derived fonts for Bold Italic though. notice that the 22 has Undelined and Italic-Underlined too > > Also, is there a specific reason bitmaps for Italic underlined is included for size 12, and no others? > I don't know why but it seems that it is like that in Cuis. Maybe Juan could tell us ? I've only implemented some methods in order to automatically extract them from Cuis. Alain > Cheers, > Henry >

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Igor Stasenko

2010/9/23 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On Sep 23, 2010, at 4:03 07PM, StÃ©phane Ducasse wrote: > > igor > > May be a layer for people that are not fluent with assembly would help. > Make the path easy from FFI writing. > > It is already, RTM :) > http://code.google.com/p/nativeboost/wiki/NBFnSpecParser > > Get some patterns so that people can learn by following patterns. > Oh, yeah.. see. I was showing an example how to implement own primitive using NativeBoost. Of course, an FFI API is there, and doing all the magic under the hood, so you dont have to know any assemler voodo: releaseDC: hdc <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout stdcall: #( int ReleaseDC ( HWND self , " handle to window" HDC hdc " handle to DC " )) module: #user32 the above is an FFI call to external function ReleaseDC, which can be found in 'user32.dll' windoze module. > Stef > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2010