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

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

by Bernardo Ezequiel Contreras

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. :) On Fri, Feb 24, 2012 at 10:17 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > 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 >

Feb. 24, 2012

[Pharo-project] [update 1.3] #13325

by Marcus Denker

13325 ----- Issue 5310: Ensure registration symmetry in ExternalSemaphoreTable users http://code.google.com/p/pharo/issues/detail?id=5310 Issue 2872: should fix equality of DateAndTime http://code.google.com/p/pharo/issues/detail?id=2872 -- Marcus Denker -- http://marcusdenker.de

Feb. 24, 2012

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

by Jan van de Sandt

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?' 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. 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. > >

Feb. 24, 2012

[Pharo-project] [update 1.4] #14355

by Marcus Denker

14355 ----- Issue 5338: World menu icons are not updated when a default tool changes http://code.google.com/p/pharo/issues/detail?id=5338 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] receiving tcp messages

by Sven Van Caekenberghe

On 24 Feb 2012, at 14:28, Tudor Girba wrote: > 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. OK, but it is still not 100% clear: who is the client and who is the server ? A web server (Apache, Seaside, ZnServer) is a long running program that accepts connections from clients (web browsers, curl, ZnClient), interprets the requests and sends responses as replies; the initiaitive lies with the client. Such a server might generate a logging stream which is usually written to a file, but it could send the logging records to a logging server (like syslogd) that collects and/or processes them. Then the server becomes a client to the logging server, the initiative for the communication lies with the server-as-logging-client. The reverse also exists: you could connect to a server (Twitter) and ask for a specific data stream to be send to you. Then the server is like a notification/messaging/queueing system (some multithreading magic will be needed). The connection initiative lies with the client, but the data stream transfer is done on the server's initiative. Sven

Feb. 24, 2012

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

by Igor Stasenko

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.

Feb. 24, 2012

Re: [Pharo-project] receiving tcp messages

by Tudor Girba

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. Cheers, Doru On Fri, Feb 24, 2012 at 2:02 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Doru, > > I meant: look at ZnServer and friends for inspiration, not to solve the problem of how to write a simple TCP server. > > If you do just: ZnServer startDefaultOn: 1701 and then talk HTTP over telnet, it will work as expected: > > $ telnet 127.0.0.1 1701 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > GET / HTTP/1.1 > > HTTP/1.1 200 OK > Content-Type: text/html;charset=utf-8 > Content-Length: 1195 > Date: Fri, 24 Feb 2012 12:51:03 GMT > Server: Zinc HTTP Components 1.0 > > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > <html> > <head> > <title>Zinc HTTP Components</title> > <style type="text/css"> > body { > Â color: black; > â¦. > > > Writing your own delegate means handling HTTP requests and answering with HTTP responses. (Zn contains a lot of these). > > But I am not sure that you should do that for your problem, on one hand it might be overkill, on the other hand, HTTP _is_ one of the easiest protocols, not need to invent something new. If you use HTTP, you get all you need with Zn. > > The question is: what is on the other side ? what is the client ? > > Sven > > On 24 Feb 2012, at 13:20, Tudor Girba wrote: > >> Hi, >> >> I advanced a bit, but I am still in trouble. >> >> I just want to get a communication going with a simple telnet app. >> Here is what I did: >> >> In Pharo: >> ZnMultiThreadedServer startDefaultOn: 1701. >> ZnMultiThreadedServer default >> Â Â Â delegate: PXSLogDelegate new. >> ZnMultiThreadedServer default >> Â Â Â log addListener: ZnTranscriptLogger new.. >> >> In the Windows 7 command line: >> - telnet localhost 1701 >> - then press ENTER >> >> And in the Transcript I get: >> 2012-02-24 13:16:57 201678 D Executing request/response loop >> 2012-02-24 13:17:02 201678 D ZnUnknownHttpMethod while reading request >> 2012-02-24 13:17:02 201678 D Closing stream >> >> The problem is that I do not want to get as high as http. Is there a >> way to get this working, or is Zinc too high level for this task? >> >> I forgot to mention that I am a total newbie in this area :) >> >> Cheers, >> Doru >> >> >> On Fri, Feb 24, 2012 at 10:56 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Thanks, Sven. Will do. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Fri, Feb 24, 2012 at 10:37 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >>>> Doru, >>>> >>>> On 24 Feb 2012, at 10:14, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> I would need to listen to a TCP/IP port and receive plain text. What >>>>> is the way to do that in Pharo these days? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>> >>>> Have a look at the ZnServer hierarchy, specifically ZnSingleThreadedServer which does not spawn threads for each incoming request (not used as such in Zn, but easier to understand) and ZnMultiThreadedServer which does spawn threads for each incoming request (the current default in Zn). Start with #listenLoop. The code is slightly more complicated that example code because of all the error handling, but I am sure you will be able to read it. >>>> >>>> HTH, >>>> >>>> Sven >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> http://stfx.eu >>>> Smalltalk is the Red Pill >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 24, 2012

Re: [Pharo-project] fun with NBOpenGL

by Henrik Johansen

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. 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. Cheers, Henry

Feb. 24, 2012

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

by Henrik Johansen

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

Feb. 24, 2012

Re: [Pharo-project] fun with NBOpenGL

by Igor Stasenko

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. > Cheers, > Henry -- Best regards, Igor Stasenko.

Feb. 24, 2012