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

Re: [Pharo-project] Support for returning external structures in NativeBoost

by Igor Stasenko

On 10 February 2012 15:55, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 February 2012 13:14, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: >> I have this wrapper: >> >> chooseVisual: display screen: aScreenNumber attributes: attribList >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> >> ^ self call: #( NBXLibVisualInfo* glXChooseVisual ( NBXLibDisplay display , >> int aScreenNumber, int *attribList ) ) >> >> but when generating native code it ends in: >> >> ExternalStructureType>>coerceReturn: gen >> >> " ... should we support handling return of external structures? " >> self error: 'returning pointer to structure?' >> >> >> Changing "NBXLibVisualInfo*" to "NBXLibVisualInfo" didn't help. Is there any >> workaround?? >> > > Yes. Change the return type to void* :) > And then do as i showed before: load the struct fields from that > pointer in your code. > > info := NBXLibVisualInfo fromPointer: (self chooseVisual: display > screen: aScreenNumber attributes: attribList) > > Because how you would implement it? It maybe a pointer to single > structure or pointer to an array of structures.. > Because in C a pointer can be a pointer to a single value, or pointer > to multiple values and you cannot make a difference. > and of course it is a good excuse for not implementing structs which accessing data indirectly (via pointer to some memory), instead of holding fields data in bytearray :) Though, it is easy to implement. So if you really can't live without it, i can add it. -- Best regards, Igor Stasenko.

Feb. 10, 2012

Re: [Pharo-project] Support for returning external structures in NativeBoost

by Igor Stasenko

On 10 February 2012 13:14, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > I have this wrapper: > > chooseVisual: display screen: aScreenNumber attributes: attribList > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^ self call: #( NBXLibVisualInfo* glXChooseVisual ( NBXLibDisplay display , > int aScreenNumber, int *attribList ) ) > > but when generating native code it ends in: > > ExternalStructureType>>coerceReturn: gen > > " ... should we support handling return of external structures? " > self error: 'returning pointer to structure?' > > > Changing "NBXLibVisualInfo*" to "NBXLibVisualInfo" didn't help. Is there any > workaround?? > Yes. Change the return type to void* :) And then do as i showed before: load the struct fields from that pointer in your code. info := NBXLibVisualInfo fromPointer: (self chooseVisual: display screen: aScreenNumber attributes: attribList) Because how you would implement it? It maybe a pointer to single structure or pointer to an array of structures.. Because in C a pointer can be a pointer to a single value, or pointer to multiple values and you cannot make a difference. -- Best regards, Igor Stasenko.

Feb. 10, 2012

[Pharo-project] Support for returning external structures in NativeBoost

by Javier PimÃ¡s

I have this wrapper: chooseVisual: display screen: aScreenNumber attributes: attribList <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self call: #( NBXLibVisualInfo* glXChooseVisual ( NBXLibDisplay display , int aScreenNumber, int *attribList ) ) but when generating native code it ends in: ExternalStructureType>>coerceReturn: gen " ... should we support handling return of external structures? " self error: 'returning pointer to structure?' Changing "NBXLibVisualInfo*" to "NBXLibVisualInfo" didn't help. Is there any workaround?? -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Feb. 10, 2012

[Pharo-project] [update 1.4] #14326 NonInteractiveUIManager improved

by Marcus Denker

14326 ----- Issue 5227: NonInteractiveUIManager should implement #syntaxErrorNotificationDefaultAction: http://code.google.com/p/pharo/issues/detail?id=5227 Thanks Camillo Bruni! Primarily fixed startup errors for loaded scripts - CodeLoader prints out SyntaxErrors and the filename if a script fails to load - added CommandLine UIManager which should be an interactive implementation for being used on the terminal - NonInteractiveUIManager inherits from CommandLine UIManager so that the logging facility can be shared - Cleaned up SyntaxError - added direct initializers with SyntaxErrorNotification: - properly color the displayed code - selec the error message - display the error message in the title - double click on the class name opens the debugger - Cleaned up users of SyntaxErrorNotification: - provide the code in raw format without included error message - changed the notion of headless and interactive on SmalltalkImage - headless == no display attached - noninteractive == no user input (previously the negation of headless) - added new possible commmandline option -interactive - added convenience method in String >> #lineNumberCorrespondingToIndex: used for formatting the syntax errors -- Marcus Denker -- http://marcusdenker.de

Feb. 10, 2012

[Pharo-project] Moving parsing out of code generator in NativeBoost

by Javier PimÃ¡s

This is mainly for Igor, but anyone interested on NB can participate. For the topic parser/code generator. I been thinking about the parts of the changes we've been talking about. The are dozens of classes that implement asNBExternalType: generator, but only string/char uses the generator, to access an instance variable and know if should use wide or byte strings/chars. In the end, I think the dependency parser->generator is artificial and should be removed (maybe by creating some "environment object") but I need to think how. But I think that we can do something in the middle meanwhile. What I'd like is the generator to take care of *only* generating code. Or at least, if that is not possible, to keep the unrelated code on it to the minimum. Specially, to move out the parts that deal with strings. It's obvious that the gen needs a parsed version of the function specs, but if most of this parsing is done outside, the best. In that direction I pushed some code which I think you'll like more this time. The idea is that the generator creates a translator object, that takes the raw func spec (stings) and with it's aid creates a new one that has the external types. The only aid the parser needs is to resolve types, because type resolving may depend on options. Then, it doesn't do it itself but uses the type resolver, because again, most of this work is to deal with strings, and doesn't need the generator directly so it can be done outside. Give the code a look, it's in better shape -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Feb. 10, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Igor Stasenko

On 10 February 2012 10:19, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >>> All you need to do is to send it a stream. If the >>> stream is already at a certain position, it doesn't matter it will start >>> from that position. Say you have stream where you write something first >>> and >>> then you give it to Fuel to serialize. The stream would be at some >>> position >>> different than zero. Say, at position 10. Fuel will start serializing for >>> there. Say we have written 40 bytes. Â Then, at materialization, when you >>> give it the stream, you have to be sure to give the stream starting at >>> the >>> position 10. >> >> However if you consider Fuel "the standard file format" - this would >> appear to be broken by people using random offsets. > > > > yes, sure. But I think its ok to fail from the serializer point of view. It > is YOUR responsability to provide the correct streams. > > >>> >>> Fuel will load EXACTLY 40 bytes and will stop. The stream can >>> continue....fuel doesn't care and it will store exactly when it finishes >>> reading his own bytes. >>> >>> BTW, this is how some databases work. The save several serialized objects >>> in the same stream... >>> >> >> To reach for the moon... Perhaps Fuel "the standard file format" holding >> multiple streams might be formalized by tagging different each stream with a >> 'name' and/or a 'type' and/or 'deserializerMethod'. Â The first two of these >> might be '#fuel -> #fuelDeserializer' and '#meta->#textDeserializer'. > > > I don't understand. Fuel holding multiple streams ? why? for what? > >> >> Â The the default Fuel system can then automatically ignore 3rd-party data. > > > I want to make my point clear: Martin proposed an example that solves Yanni > problem. If you serialize with a stream with a certain position, then you > have to materialize it with its correct position. Dot. It is perfect that > the materializer is broken if you do not give him the correct stream. > Now, I DO agree that there could be another solution rather than adhoc, > supported by fuel so that BY DEFAULT some data could be set and ignored at > the same time...so that there is no manipulation of the srteam by the user. > > no i think your approach is fine. you store what you need, and don't care/intervene with other parts of stream, so if user wants to add some stuff before materialized data, he free to do so. -- Best regards, Igor Stasenko.

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Igor Stasenko

On 10 February 2012 11:33, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > That's precisely what I'm trying to do. Â Sig's answer might provide a piece of the puzzle, but I still have to figure out whether/why/how the problem really does persist after executing code and not saving the image. Â I added some snapshots thinking I could take success as it comes and repeat steps that failure, but I removed them all (I think) when I started to discover that once hobbled, the image remains hobbled, saved or not. Â Weird. > yes, the problem is when you have an error and i had wrong idea to suspend a process before scheduling request to open debugger on it :) > For all I know, I have made this reproducible. Â One response said essentially, "yeah, I sometimes just load the packages MC would load" - hardly the way one speaks of a robust infrastructure. > > > > ________________________________________ > 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 10, 2012 5:26 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 1.4 - better from Jenkins > > On Feb 10, 2012, at 11:22 AM, Schwab,Wilhelm K wrote: > >> Dale, >> >> I'm not "complaining," I'm stating facts and asking for advice. Â Not only did I state that I produced a "big" debug log, I also POSTED a smaller one. Â If you mean something different by a "stack trace," can you provide some instructions for how to obtain it? >> > What we need is a description of how to re-produce the problem. > Do not think that anyone can (or even wants to help) if you just say "I did something and than I got strange results". > > Make it reproducable, and then add a bug report. > > Â Â Â Â Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Best regards, Igor Stasenko.

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Nick Ager

Hi Bill, I've reading about your trails with Monticello/Metacello and been surprised about all the difficulties you are having. I frequently load fairly complex configurations on top of Pharo 1.3 without a problem. You can flush Monticello caches with: MCMethodDefinition cachedDefinitions removeAll. MCFileBasedRepository allSubInstancesDo: [:ea | ea flushCache]. and try removing the 'package-cache' folder from the folder containing your image. other than that, as others have said if you can isolate the problem we stand a chance of helping you Nick

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Schwab,Wilhelm K

That's precisely what I'm trying to do. Sig's answer might provide a piece of the puzzle, but I still have to figure out whether/why/how the problem really does persist after executing code and not saving the image. I added some snapshots thinking I could take success as it comes and repeat steps that failure, but I removed them all (I think) when I started to discover that once hobbled, the image remains hobbled, saved or not. Weird. For all I know, I have made this reproducible. One response said essentially, "yeah, I sometimes just load the packages MC would load" - hardly the way one speaks of a robust infrastructure. ________________________________________ 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 10, 2012 5:26 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins On Feb 10, 2012, at 11:22 AM, Schwab,Wilhelm K wrote: > Dale, > > I'm not "complaining," I'm stating facts and asking for advice. Not only did I state that I produced a "big" debug log, I also POSTED a smaller one. If you mean something different by a "stack trace," can you provide some instructions for how to obtain it? > What we need is a description of how to re-produce the problem. Do not think that anyone can (or even wants to help) if you just say "I did something and than I got strange results". Make it reproducable, and then add a bug report. Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Marcus Denker

On Feb 10, 2012, at 11:22 AM, Schwab,Wilhelm K wrote: > Dale, > > I'm not "complaining," I'm stating facts and asking for advice. Not only did I state that I produced a "big" debug log, I also POSTED a smaller one. If you mean something different by a "stack trace," can you provide some instructions for how to obtain it? > What we need is a description of how to re-produce the problem. Do not think that anyone can (or even wants to help) if you just say "I did something and than I got strange results". Make it reproducable, and then add a bug report. Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 10, 2012