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

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

by Jan van de Sandt

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 ) ) Jan. On Tue, Feb 14, 2012 at 10:10 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 February 2012 22:59, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > I started with a new image and loaded ConfigurationOfNativeBoost. But > it's > > still not working. > > > > First I do a call to get a handle: > > > > "UEnumeration* ucal_openTimeZones(UErrorCode * ec)" > > > > self nbCall: #( void* ucal_openTimeZones_48( ICUErrorCodeNB* anErrorCode > ) ) > > module: 'libicui18n.dylib' > > > > This call succeeds. I store the result in a subclass of NBExternalHandle > > using the #value: class method. > > > > In the second call I want to use the handle to retrieve the next element: > > > > self nbCall: #( char* uenum_next_48(ICUEnumerationNB* aHandle, int* nil, > > ICUErrorCodeNB* anErrorCode ) ) module: 'libicuuc.dylib' > > > > But this call still causes the image to disappear. I think the nil and > > errorCode arguments are all right. Is there something wrong with the > first > > argument? > > I cannot say precisely, because i don't see a code.. so lets see.. > > UEnumeration* U_EXPORT2 ucal_openTimeZones ( UErrorCode * ec > ) > > returns a pointer. > And you storing the pointer value to instance of ICUEnumerationNB > > > Now i guess that next function should take that pointer value: > > char* uenum_next_48(ICUEnumerationNB aHandle, int* nil, > ICUErrorCodeNB* anErrorCode ) > > but not a pointer to pointer value, like you wrote: > > char* uenum_next_48(ICUEnumerationNB* aHandle, int* nil, > ICUErrorCodeNB* anErrorCode ) > > > > > > Jan. > > > > > > > > > > > > On Tue, Feb 14, 2012 at 11:34 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 13 February 2012 22:40, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > >> > Hello list, > >> > > >> > I want to call the following C function using NativeBoost: > >> > > >> > const char* uenum_next(UEnumeration * en, int32_t * resultLength, > >> > UErrorCode > >> > * status) > >> > > >> > According to the (icu4c) documentation you can pass NULL for the > >> > resultLenth > >> > argument [1]. But when I try: > >> > > >> > self nbCall: #( char* uenum_next_48( self, nil, ICUErrorCodeNB* > >> > anErrorCode > >> > ) ) module: 'libicuuc.dylib' > >> > >> should be no problem. > >> you can try also to just pass zero, if it make any difference > >> > >> self nbCall: #( char* uenum_next_48( self, 0 , ICUErrorCodeNB* > >> anErrorCode ) ) module: 'libicuuc.dylib' > >> > >> (in fact code generator should produce same code, since nil > >> substituted by 0 at the end). > >> > >> Maybe the problem is not there, but in other arguments you passing. > >> > >> And, i recommend you to use ConfigurationOfNativeBoost from > >> NBInstaller, but not latest packages directly, since Javier put a lot > >> of changes lately and some parts might not work properly. > >> > >> > >> > > >> > My image craches. Does anyone know what I'm doing wrong? > >> > > >> > Jan. > >> > > >> > > >> > [1] > http://icu-project.org/apiref/icu4c/uenum_8h.html#a99298eabaa3874cdfd9793b2… > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Feb. 24, 2012

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

by Sven Van Caekenberghe

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

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

by Norbert Hartl

Bill, Am 24.02.2012 um 11:12 schrieb Schwab,Wilhelm K: > 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? no, it is not saying nothing. Your reply to Marcus' mail (if it is in the list) is exactly what Marcus meant. Nobody (including me) takes the time to add something. A question is written quickly but at the same time you are making your own case easy while wasting someone elses time. Excuses are the wrong reaction IMHO. Writing a couple of emails and state that you don't have time is a contradiction. It is one that we like to oversee because we are lazy guys. So if you need an advize from me than I would suggest that while you are tired write it down on a piece of paper. On the next day spend some fresh time scanning the issue tracker and come up with something substantial being either a new bug entry or a concrete question. Norbert > ________________________________________ > 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 5:08 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 > > On 24 Feb 2012, at 10:56, Schwab,Wilhelm K wrote: > >> If memory serves, this has been reported (Sig, I'm thinking of the even sensor or similar bug) and is a known problem. I did look over the list, don't see it mentioned, at least not in terms that jump out at me. Could be wrong. It's a BAD bug IMHO. > > Look, I know you are not making this up and are trying to more forward, BUT: you really, really, have to provide a detailed bug report before anyone can even try to help you. You write software yourself, you presumably have users for it, you know how this works. > > You are describing things in very general terms and use strong negative adjectives, this won't work. > > Give us a (short/simple) way to reproduce your problem, please. > > Sven >

Feb. 24, 2012

Re: [Pharo-project] fun with NBOpenGL

by Henrik Johansen

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

Feb. 24, 2012

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

by Schwab,Wilhelm K

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? ________________________________________ 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 5:08 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 On 24 Feb 2012, at 10:56, Schwab,Wilhelm K wrote: > If memory serves, this has been reported (Sig, I'm thinking of the even sensor or similar bug) and is a known problem. I did look over the list, don't see it mentioned, at least not in terms that jump out at me. Could be wrong. It's a BAD bug IMHO. Look, I know you are not making this up and are trying to more forward, BUT: you really, really, have to provide a detailed bug report before anyone can even try to help you. You write software yourself, you presumably have users for it, you know how this works. You are describing things in very general terms and use strong negative adjectives, this won't work. Give us a (short/simple) way to reproduce your problem, please. Sven

Feb. 24, 2012

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

by Sven Van Caekenberghe

On 24 Feb 2012, at 10:56, Schwab,Wilhelm K wrote: > If memory serves, this has been reported (Sig, I'm thinking of the even sensor or similar bug) and is a known problem. I did look over the list, don't see it mentioned, at least not in terms that jump out at me. Could be wrong. It's a BAD bug IMHO. Look, I know you are not making this up and are trying to more forward, BUT: you really, really, have to provide a detailed bug report before anyone can even try to help you. You write software yourself, you presumably have users for it, you know how this works. You are describing things in very general terms and use strong negative adjectives, this won't work. Give us a (short/simple) way to reproduce your problem, please. Sven

Feb. 24, 2012

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

by Marcus Denker

On Feb 24, 2012, at 10:57 AM, Schwab,Wilhelm K wrote: > If memory serves, this has been reported (Sig, I'm thinking of the even sensor or similar bug) and is a known problem. I did look over the list, don't see it mentioned, at least not in terms that jump out at me. Could be wrong. It's a BAD bug IMHO. > Bug tracker number? -- Marcus Denker -- http://marcusdenker.de

Feb. 24, 2012

Re: [Pharo-project] Increasing bots traffic

by Marcus Denker

On Feb 24, 2012, at 10:35 AM, Pavel Krivanek wrote: > On Fri, Feb 24, 2012 at 7:15 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Feb 23, 2012, at 10:46 PM, Nicolas Cellier wrote: >> >>> Just curious, what is the goal of Jenkins build reports >>> - focus developers attention on failing tests >> >> The reports will stop as soon as the build is green. >> >> But in general, the *only* person who has *ever* >> added a bug report because a test started to fail was me. >> >> Nobody looks at the failing tests! > > > I understand your indignation but last week I tried to look at failing > tests of 1.4 and make it green (however without full success because > some are VM related) :-) Yes, thanks and sorry... if I happen to stare at the bug tracker too long I get strange. Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 24, 2012

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

by Schwab,Wilhelm K

If memory serves, this has been reported (Sig, I'm thinking of the even sensor or similar bug) and is a known problem. I did look over the list, don't see it mentioned, at least not in terms that jump out at me. Could be wrong. It's a BAD bug IMHO. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Tudor Girba [tudor(a)tudorgirba.com] Sent: Friday, February 24, 2012 4:28 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 Bill, Please look over the list to find the answer to your question. Cheers, Doru On Fri, Feb 24, 2012 at 10:24 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Is the missing debugger on your list? I have found 1.3 (speaking as a friend here) to be unusable over this. I get some work done with it, and then debuggers stop opening, rendering the image useless (AFAIK). > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Marcus Denker [marcus.denker(a)inria.fr] > Sent: Friday, February 24, 2012 2:57 AM > To: An open mailing list to discuss any topics related to an open-source Smalltalk > Subject: [Pharo-project] [Bug Tracker] Issues tagged 1.3 > > Hi, > > Just as another suggestion of something else to do to uselessly talk about what one would > do if one could do... here is something that needs to be done: > > http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3 > > Someone need to looks at each issue and as questions. > > - can this problem be repeated in the current last version of 1.3? > - is this already fixed in 1.4? if yes > -- is it so grave that the fix needs to be backported? > - was it already a bug for the last 10 years and it did not hurt? > -- Hint, hint: likely not important for fixing in 1.3 after it has been released. > (yet, it could be. And if the fix is easy and clearly not breaking anything) > - is there already a bug report about this issue on the tracker? > (you have no idea how many reports are duplicated entries...) > - What could be the reason for the problem? What could be a possible fix? > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 24, 2012

Re: [Pharo-project] receiving tcp messages

by Tudor Girba

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"

Feb. 24, 2012