February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] receiving tcp messages

by Sven Van Caekenberghe

On 24 Feb 2012, at 15:42, GÃ¶ran Krampe wrote: > On 02/24/2012 02:28 PM, Tudor Girba wrote: >> Hi Sven, >> >> Thanks, but I did not explain my problem correctly. My problem is >> actually super trivial. I have a server that throws continuously plain >> text (actually, it's a logging facility), and I need to implement a >> client that connects to it and consumes the plain text endlessly >> without any feedback to the server. So, essentially, there is no >> communication protocol involved. > > Just use SocketStream. Since you are building a client it is trivial: > > stream := SocketStream openConnectionToHostNamed: host port: port. > [stream isConnected] whileTrue: [ > line := stream nextLineLf] > > ...or something like that (just see protocol of SocketStream). No need to use Socket directly - I tend to keep repeating that on mailinglists. :) > > For a trivial *forking server* you can load Blackfoot from SS and "copy" from it, it is a stripped down server basically. > > regards, GÃ¶ran He wants a server, I think. Here is an example of a very simple forking server, without error handling code: | serverSocket serverProcess | serverSocket := Socket newTCP. serverSocket listenOn: 8888 backlogSize: 5. serverProcess := [ [ | clientSocket stream line | clientSocket := serverSocket waitForAcceptFor: 900. stream := SocketStream on: clientSocket. [ [ (line := stream nextLine) ~= 'quit' ] whileTrue: [ Transcript crLog: line. stream nextPutAll: line reverse; crlf; flush ]. stream close ] fork. ] repeat ] fork. { serverProcess. serverSocket }. And here is how it works: $ telnet 127.0.0.1 8888 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. hello olleh doru urod smalltalk klatllams quit Connection closed by foreign host. Make sure to inspect the code above, so that you can #terminate the server process and #close the server socket. The process browser is useful too (don't forget to update it), as will be Socket allInstances and/or Socket allInstances do: #close (Warning: you will crash/hang your image until you get this 100% right with proper error handling.) HTH, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 24, 2012

Re: [Pharo-project] [Bug Tracker] Issues that need to be reviewed

by Nicolas Cellier

Le 24 fÃ©vrier 2012 14:17, Henrik Johansen <henrik.s.johansen(a)veloxit.no> a Ã©crit : > On Feb 24, 2012, at 1:35 PM, Nicolas Cellier wrote: > >> I systematically mark my fixes as ReviewNeeded because a second pair >> of eyes don't hurt. >> But this seems to be yet another bottleneck. >> Taking responsibility to review might seem scary and involving >> especially when changes touch obscure/complex part of the system. >> >> So maybe the review could take lighter, more or less automated forms: >> - does automated integration reports a regression ? >> - does the bug report gives enough technical solution details or a >> good rationale ? >> - are there some tests provided ? >> >> Maybe you could handle a confidence score per developer. with a priori >> and a posteriori informations. >> Like "good solution, but the integrator had more work to finish the job"... >> >> On the other hand, Pharo claims the right to do some mistakes (and >> soon correct them), so maybe this review phase could be relaxed a bit. >> >> And one thing I still ask for is a diff log for each SLICE posted in >> the inbox, entirely browsable from the issue tracker or from the bug >> list, because to review you need: >> - to read issue tracker report >> - AND to inspect the changes with Monticello merge in a recent clean image... >> Having the diff would be a great economy for the reviewers. >> Or maybe this already happened? >> >> Maybe the report generated by Monticello that pops up once the package >> commited, could contain such diff that we would manually copy/past in >> the bug entry. Would that be cheap enough ? >> >> Nicolas > > +999. > > I don't mind reviewing changes, but loading up an image, updating it to latest version to ensure any conflicts are caught, opening MC browser, finding the slice, diffing against image, and only THEN be able to do a decent review are just too many manual steps, other than for issues I care very strongly about. (in which case I'm often the one requesting ReviewNeeded to begin withâ¦) > > IMHO, doing all the above, and reporting merge conflicts/ new failed tests/a diff to the issue would be a perfect task for UlyssÃ© :) > (As it is now, "Monkey went bananas" doesn't really tell me anything) > > Cheers, > Henry Obviously, when you see there is a regression, test previously green (blue) and now red, you want to see which SLICE was loaded and in deeper details what changed in code if you want to quickly identify and fix the cause... How do you diff source code between two Jenkins build currently? Ideally such information should be accessible directly from the Jenkins report... Nicolas

Feb. 24, 2012

Re: [Pharo-project] NB How can I pass a NULL argument?

by Igor Stasenko

On 24 February 2012 15:02, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Thanks for the explanation, it starts to make sense to me now. But when I > change the return type of the first call from "void*" toÂ ICUEnumerationNB I > end up here: > > NBExternalStructureType>>coerceReturn: gen > > " ... should we support handling return of external structures? " > self error: 'returning pointer to structure?' > This happens when you putting a pointer to struct as return value in function signature, which means that you doing something wrong, or modified code in different place. What i see (in ICU-NativeBoost-Core-jvds.3) is following : nbTestprimOpenTimeZones: anErrorCode <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( ICUEnumerationNB___>>>>_*__<<<< remove it___ ucal_openTimeZones_48( ICUErrorCodeNB* anErrorCode ) ) and once you will do that, the error you see will go away. but i cannot call the function since i don't have the corresponding library on my machine, have binaries somewhere for download?. > The problem is not so urgent for me anymore because I can work around it > using justÂ NBExternalAddress instances. But off course I'm still curious to > know what's the best way to handle these kind of native calls. > I takes time to get used to it. I know by myself that interfacing with C is confusing, especially when dealing with pointers. > Jan. > > PS: The code is > inÂ http://www.squeaksource.com/ICU.htmlÂ Â ICUCalendarNB>>#nbTestAllTimeZones > > > > On Fri, Feb 24, 2012 at 2:35 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 24 February 2012 12:10, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: >> > Hi, >> > >> > Well, it works if I don't use the ICUEnumeration class. The first call >> > returns an NBExternalAddress instance. If I pass this instance to the >> > second >> > call than it works fine. The native call looks like this: >> > >> > self nbCall: #( char* uenum_next_48(void* aHandle, nil, ICUErrorCodeNB* >> > anErrorCode ) ) >> > >> > My idea was to use a subclass ofÂ NBExternalHandle where I can put all >> > the >> > functions related to this handle. But itÂ stops working when I copy the >> > value >> > from the ExternalAddress to my handle subclassÂ ICUEnumerationNB and use >> > one >> > of these calls: >> > >> > self nbCall: #( char* uenum_next_48(ICUEnumerationNB* aHandle, nil, >> > ICUErrorCodeNB* anErrorCode ) ) >> > >> > or >> > >> > self nbCall: #( char* uenum_next_48(ICUEnumerationNB aHandle, nil, >> > ICUErrorCodeNB* anErrorCode ) ) >> > >> >> Since NBExternalHandle is variable byte class, >> if you pass a pointer to it, like >> ICUEnumerationNB* then FFI will push a pointer to the first indexable >> byte in ICUEnumerationNB instance, >> but not the value of handle stored in this instance. >> In your case, you stored UEnumeration*, but then you pushing >> UEnumeration**, while function expects UEnumeration*. >> >> It is hard to say, why "ICUEnumerationNB aHandle" doesn't works for >> you without looking at code, especially >> that NBExternalAddress is a subclass of NBExternalHandle. >> >> You can try the following: >> >> Since both functions working with same type (UEnumeration*) , Â you can >> actually treat it as if you would have >> >> typedef UEnumeration* ICUEnumerationNB; >> in C. >> >> So, then just remove '*' everywhere (in function which returns it, and >> in functions where you passing it as argument): >> >> self nbCall: #( ICUEnumerationNB ucal_openTimeZones_48( >> ICUErrorCodeNB* anErrorCode ) ) >> >> and: >> self nbCall: #( char* uenum_next_48(ICUEnumerationNB aHandle, nil, >> ICUErrorCodeNB* anErrorCode ) ) >> >> that should work fine, unless that library doing something strange >> (which also might be the case ;). >> >> P.S. originally, i intentionally raising an error when you passing a >> pointer to NBExternalAddress or Handle types >> (so is allows to pass a just a value, but not a pointer to the value) >> to prevent mistakes like that. >> But some functions actually wanting to get a pointer to the pointer >> (like int** etc), so then they can store a pointer at that pointer, >> and i was added that, because it is convenient. >> >> P.P.S Yo dawg, i put a pointer to that pointer so you can point to >> what it points ;) >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Feb. 24, 2012

[Pharo-project] R: Migrating from VSE

by Lorenzo Schiavina

Hi Krish, If you look at this address http://www.smalltalking.net/indexe.htm you can find information about a project to restyle VSE but not in Pharo. Lorenzo _____ Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di S Krish Inviato: giovedÃ¬ 23 febbraio 2012 9.28 A: pharo-project(a)lists.gforge.inria.fr Oggetto: [Pharo-project] Migrating from VSE Can anyone can throw in the challenges in migrating VSE into Pharo.. UI -> Morphic a big change.. rest of the code -> Pharo base.. do we have grease / or anything akin.. to ease migration Or is it simply the same effort as pushng this into VW where it would stand better guarantees..? both from a corporate plan/ support etc.

Feb. 24, 2012

Re: [Pharo-project] receiving tcp messages

by GÃ¶ran Krampe

On 02/24/2012 02:28 PM, Tudor Girba wrote: > Hi Sven, > > Thanks, but I did not explain my problem correctly. My problem is > actually super trivial. I have a server that throws continuously plain > text (actually, it's a logging facility), and I need to implement a > client that connects to it and consumes the plain text endlessly > without any feedback to the server. So, essentially, there is no > communication protocol involved. Just use SocketStream. Since you are building a client it is trivial: stream := SocketStream openConnectionToHostNamed: host port: port. [stream isConnected] whileTrue: [ line := stream nextLineLf] ...or something like that (just see protocol of SocketStream). No need to use Socket directly - I tend to keep repeating that on mailinglists. :) For a trivial *forking server* you can load Blackfoot from SS and "copy" from it, it is a stripped down server basically. regards, GÃ¶ran

Feb. 24, 2012

Re: [Pharo-project] [update 1.4] #14355

by Pavel Krivanek

On Fri, Feb 24, 2012 at 3:37 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Fri, Feb 24, 2012 at 2:55 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> 14355 >> ----- >> >> Issue 5338: Â Â World menu icons are not updated when a default tool changes >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5338 > > This fix adds dependency on Morphic to AppRegistry class >> #default > so Pharo Kernel cannot be produced. > > Cheers > -- Pavel http://code.google.com/p/pharo/issues/detail?id=5370 -- Pavel > >> >> Issue 5325: Â Â PackageInfo dependent on deprecated MethodReference >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5325 >> >> >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >>

Feb. 24, 2012

Re: [Pharo-project] [update 1.4] #14355

by Pavel Krivanek

On Fri, Feb 24, 2012 at 2:55 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 14355 > ----- > > Issue 5338: Â Â World menu icons are not updated when a default tool changes > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5338 This fix adds dependency on Morphic to AppRegistry class >> #default so Pharo Kernel cannot be produced. Cheers -- Pavel > > Issue 5325: Â Â PackageInfo dependent on deprecated MethodReference > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5325 > > > > > -- > Marcus Denker -- http://marcusdenker.de > >

Feb. 24, 2012

Re: [Pharo-project] fun with NBOpenGL

by Igor Stasenko

On 24 February 2012 14:26, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Feb 24, 2012, at 2:04 PM, Igor Stasenko wrote: > >> On 24 February 2012 11:22, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>> On Feb 24, 2012, at 4:05 AM, Igor Stasenko wrote: >>> >>>> >>>> Anyways, i don't like the fact that it copying the rendered stuff from >>>> video memory back to main memory, >>>> and then copying stuff back to video memory (but this time by morphic + VM). >>>> But this was a cheap way to get demo working and morphic integration. >>>> >>>> If i would be making app which using opengl for rendering, i would >>>> never copy things like that, >>>> because it just a waste of cycles causing a big impact to frame rate. >>>> What works for demo, is not really applicable in serious application. Â :) >>>> In serious app, i'd rather copy morphic Display form into separate >>>> texture and then render it along with other Â stuff, which is already >>>> in video memory. >>>> But this approach needs more time investments, which currently i don't >>>> have, and actually heavily depends >>>> on what you want from your app. >>> >>> I think you'd have to ditch the idea of rendering the Display bitmap entirely, if you want to write GL windows to screen directly. >>> Otherwise, you would _never_ get compositing correct, think translucent morphs on top of the GL window for example. >>> >> Yes, but this is for cases if i want to make opengl stuff embedded >> into morphic world. But if i don't want it, i don't need to care :) >> >>> As such, you'd need to rewrite the entire compositing window manager using GL buffers, and only as a side-effect flush the rendering results to a Display there for purely backwards-compatability reasons. >>> >> >> If we would have an easy control of host windows, i.e. a way to create >> new windows and create GL contexts for them in a way we want. >> But today's VMs having little for that. What needs to be done first is >> to make image to be in direct control of host windows, so then >> we can control GL & Display in a way we want. >> Because right now, VM doing "magic" with main window by binding >> Display form to it , and the code which updates it also there, so you >> simply >> cannot do any compositing et all , since the code you need to modify >> is on VM side. > > Multiple window support is orthogonal to compositing OGL/Morphic correctly through writing a window manager (badly worded, I meant composition manager) for the current way display is handled. > Unfortunately, if i would control creation of main window (and hence creation of GL context for it ), then it would be much easier to sidestep all VM functionality and use flicker-free things like swapBuffers, when update to window is required. So, it is not quite orthogonal, because if you look at Mac VMs, its using opengl by its own and it means that it creating own gl context and managing it behind the scenes (see sqSqueakOSXNSView.m in platforms/iOS/vm). > You'd theoretically only need two things from the VM to do so; a handle to the context of the current window; and a way to modify the Display that does not automatically trigger a "built-in" redisplay. > The compositing in that window could all use VBO/FBO's (bound to said context of course), and display done directly by the (written in smalltalk, using OGL to display) composition manager, sidestepping all VM logic. (well, and ensuring you redraw *after* VM logic triggers automatically, like when window is resized) > As long as the Display bitmap is updated accordingly as well, external users shouldn't even be affected. > what would be really nice is to have callbacks to language side when request to update is received. Then i can decide what to do in order to update the window. But right now i'd rather avoid investing too much effort in "seamless" integration of morphic and GL, because without changing the VM interface the implementation will be cumbersome and will contain many different bells and whistles... The central part of OpenGL game is controlling creation of context and its various parameters. Without such control you often cannot ensure that you will have certain hardware functionality accessible, because depending on the way how you creating a context OS may block it and provide oldish or even software-based renderer for you. -- Best regards, Igor Stasenko.

Feb. 24, 2012

Re: [Pharo-project] [Bug Tracker] Issues that need to be reviewed

by Henrik Johansen

On Feb 24, 2012, at 3:08 PM, Bernardo Ezequiel Contreras wrote: > I agree that everything (that could be done automatically) should be automated (By Ulysse or whatever), but you need > some human interaction to see if the change is good enough (coherent, consistency, design flaws, etc.). > As a newbie i'm always looking for someone to review my easy fixes. :) > Absolutely, what I wrote was intended to be about how to facilitate that human interaction by improving the parts of that process which are automatable, and in fact so cumbersome that the barrier to actually reviewing is in most cases too high. I doubt you would find anyone arguing a review can be fully automated with satisfying results. :) Cheers, Henry

Feb. 24, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by Schwab,Wilhelm K

Guys, I'm hoping Sig will see this an immediately know what is at play. I don't even know if there is a fix, but there appears to be in 1.4. If backporting that to 1.3 is feasible, it should be done. I *think* I know some keywords that might pull his relevant reply (something like "you are a victim of") from the archive. Can't do it right now. BTW, I took Stef's reply and used it to good effect - might have even figured out why I couldn't build images. All part of testing. If you look, you'll find code of mine in the image. Have you noted some of my responses to help others - probably not. But I would rather not play "I haven't seen" games. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Friday, February 24, 2012 6:02 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 On 24 Feb 2012, at 11:12, Schwab,Wilhelm K wrote: > There is a tracker entry, but please understand it's the middle of the night here and I'm in and out. I think Sig will know the details more off the top, otherwise I'll search later. Would you rather I say nothing about a known bug? I can't find anything with Schwab, Bill or Wilhelm in any issue ever in http://code.google.com/p/pharo/issues/list (there are a handful that are more than half a year old, magically you even received help). I read this mailing list all the time, I can't remember seeing a concrete, reproduceable bug report. Please, correct me if I am wrong. Some, like Stef, even took the trouble of trying to load some of the stuff that was causing you trouble, only to report that it worked for them. I and many others ask for help and report problems here all the time. It is incredible how people spring up all the time to help others with both simple and deep problems. It is often so that the one reporting a problem did something wrong himself, I am guilty here as well, but even then people took the trouble to look and give some of their valuable time. The way you ask the question makes a huge difference: provide details, make it reproduceable, don't include negative stuff. I'll make you a promise: I'll give you some of my personal time to try whatever you report next as 'BAD bug, makes 1.3 unstable, rendering the image useless', provided there is a description of how I should do it. Sven

Feb. 24, 2012