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

[Pharo-project] FFI - passing string to function as char*

by recursive68＠gmail.com

Hi, I'm trying to pass a smalltalk string to a FFI wrapper method I've written, the C function uses a macro "type" for the argument, but as far as I can see is basically a char* type. I've tried using char* as the argument type and it fails values to pass the string argument. If I change the argument type to a void* it works sort of partially, it passes additional memory values if I pass more than one argument to a version of the function with multiple arguments. As I understand it FFI should handle strings and coerce them to null terminated char* values when char* is used as the argument type. Is there something I'm missing, not understanding (very possible). I had similar problems when passing integer values but fixed that by using WordArray for the smalltalk type. Is there a similar fix for string objects, or someway other way of null terminating the string ? Thanks

April 28, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Schwab,Wilhelm K

It seems very reasonable to have such a crucial infrastructure to have some base support in the core image. But I have had experts tell me to *never* load a symbolic version. There is a gap to close... ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Saturday, April 28, 2012 12:08 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Schwab,Wilhelm K wrote > > Put another way, if it's that simple, why all the contrary instructions > over time? > I understand your frustration. We are like parents watching a child grow up... For one thing, the API has been evolving as we've learned. From loadLast/Latest, to bleedingEdge/development, now to symbolic versions (which were sorely needed). The other impediment was that Metacello couldn't be assumed to have preloaded any base classes. Thus, ConfigurationOfXxx classes rely on someone manually (or automatically via tools) adding convenience methods. Without these, the API is hidden away in the project class. Recently, there seemed to be some agreement between Squeak and Pharo to load some base Metacello classes. If Configs had a common subclass, I think the system browser would be much more helpful. Dale, what do you think about all this? HTH, Sean p.s. of course ultimately, success depends on people testing projects and updating the configs... -- View this message in context: http://forum.world.st/What-about-making-the-configuration-browser-more-visi… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 28, 2012

Re: [Pharo-project] [Fwd: Re: [Newbies] Remove trailing spaces of aString]

by Benjamin

If you use Pharo, you can also do that Note that you have to change 'Selector' with 'Example', and then you can type a list of arguments separated by a dot and the expected result. (If you want some inner details, it will do something like methodFor: {_WHAT_YOU_HAVE_ENTER_}) Have fun, Ben On Apr 28, 2012, at 4:00 PM, Ben Coman wrote: > I just discovered this new "bit of magic" from the Newbies list. My first impression playing with it is that MethodFinder>>methodFor: should be somehow more prominent in Tools>Finder and also in PharoByExample book. Quite a unique feature and demonstration of Smalltalk power for newcomers. > > cheers -ben > > Am 2012-04-27 um 17:27 schrieb H. Hirzel: > >> Hello >> I use Squeak 4.3, Update 11860. >> I want to remove the trailing spaces and or tabs and LF of a String >> something like >> 'abc >> ' >> should just be >> 'abc'. >> If I remember that there was a method in class String to something >> like this. Is this correct? >> Is there a package with additional String convenience methods? > > you probably want > > 'abc ' withoutTrailingBlanks > > You can find that method by evaluating or printing > > MethodFinder methodFor: { {'abc '} . 'abc' } (a list with arguments {'abc '} and an expected result ( 'abc' )) > > HTH > > Best > -Tobias > _______________________________________________ > Beginners mailing list > Beginners(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > >

April 28, 2012

Re: [Pharo-project] CompiledMethod>>origin, traits, and bug in RPackage

by Guillermo Polito

This test reproduces the problem :) testOriginWithRequiredMethod | tr1 c1 | tr1 := self createTraitNamed: #TTT1 uses: {}. tr1 compile: 'foo ^ self explicitRequirement'. self assert: (tr1 >> #foo) origin == tr1. c1 := self createClassNamed: #CTT1 superclass: Object uses: tr1. self assert: (c1 >> #foo) origin == tr1. I'll submit an issue to integrate it. On Sat, Apr 28, 2012 at 4:41 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > In the paper it says that > > self assert: (C>>#c) origin = C. > > when m*ethod c is defined locally in class C*, which overrides its defi- > nition from Trait2. Its origin is then such a class C. > > And the definition does not stand any limitations on requirements... :/ > > I'll write some tests. > > > > On Sat, Apr 28, 2012 at 9:21 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> We should check that what we described in >> http://marcusdenker.de/publications/Duca09bTraitsAPI.pdf >> >> Stef >> >> >> On Apr 28, 2012, at 1:02 AM, Guillermo Polito wrote: >> >> > For example, the trait TPureBehavior has the method #traitComposition, >> which is an explicit requirement, and I can do >> > I have that: >> > >> > (TPureBehavior>>#traitComposition) origin. --> TPureBehavior >> > >> > which is nice. >> > Now lets suppose I create: >> > >> > Object subclass: #AAA >> > uses: TPureBehavior >> > instanceVariableNames: '' >> > classVariableNames: '' >> > poolDictionaries: '' >> > category: 'Guille' >> > >> > without creating the required traitComposition method >> > >> > (AAA>>#traitComposition) origin. --> AAA ?????????? shouldn't the >> origin be TPureBehavior? >> > >> > >> > The question is: Which is the intended behavior for the #origin of a >> method? Because that's causing an issue in RPackage :). >> > >> > >> > I've traced this, and it comes that if I have a trait method marked as >> explicitRequiriment, the following method answers just false >> > >> > CompiledMethod>>isProvided: marker >> > marker ifNil: [^ true]. >> > ^ (self isRequired: marker) not and: [(self isDisabled: marker) not] >> > >> > and then a magic ifNone: [ self ] return the receiver on the behavior, >> and that's why in both examples the method's behavior is returned instead >> of the origin. >> > Then we probably should have two methods >> > - #isProvided to see if an implementation is provided >> > - #isDefined if a definition for the method exists >> > but those names do not make me happy. >> > >> > Guille >> >> >> >

April 28, 2012

Re: [Pharo-project] CompiledMethod>>origin, traits, and bug in RPackage

by Guillermo Polito

In the paper it says that self assert: (C>>#c) origin = C. when m*ethod c is defined locally in class C*, which overrides its defi- nition from Trait2. Its origin is then such a class C. And the definition does not stand any limitations on requirements... :/ I'll write some tests. On Sat, Apr 28, 2012 at 9:21 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > We should check that what we described in > http://marcusdenker.de/publications/Duca09bTraitsAPI.pdf > > Stef > > > On Apr 28, 2012, at 1:02 AM, Guillermo Polito wrote: > > > For example, the trait TPureBehavior has the method #traitComposition, > which is an explicit requirement, and I can do > > I have that: > > > > (TPureBehavior>>#traitComposition) origin. --> TPureBehavior > > > > which is nice. > > Now lets suppose I create: > > > > Object subclass: #AAA > > uses: TPureBehavior > > instanceVariableNames: '' > > classVariableNames: '' > > poolDictionaries: '' > > category: 'Guille' > > > > without creating the required traitComposition method > > > > (AAA>>#traitComposition) origin. --> AAA ?????????? shouldn't the > origin be TPureBehavior? > > > > > > The question is: Which is the intended behavior for the #origin of a > method? Because that's causing an issue in RPackage :). > > > > > > I've traced this, and it comes that if I have a trait method marked as > explicitRequiriment, the following method answers just false > > > > CompiledMethod>>isProvided: marker > > marker ifNil: [^ true]. > > ^ (self isRequired: marker) not and: [(self isDisabled: marker) not] > > > > and then a magic ifNone: [ self ] return the receiver on the behavior, > and that's why in both examples the method's behavior is returned instead > of the origin. > > Then we probably should have two methods > > - #isProvided to see if an implementation is provided > > - #isDefined if a definition for the method exists > > but those names do not make me happy. > > > > Guille > > >

April 28, 2012

[Pharo-project] [Fwd: Re: [Newbies] Remove trailing spaces of aString]

by Ben Coman

I just discovered this new "bit of magic" from the Newbies list. My first impression playing with it is that MethodFinder>>methodFor: should be somehow more prominent in Tools>Finder and also in PharoByExample book. Quite a unique feature and demonstration of Smalltalk power for newcomers. cheers -ben Am 2012-04-27 um 17:27 schrieb H. Hirzel: > Hello > > I use Squeak 4.3, Update 11860. > > I want to remove the trailing spaces and or tabs and LF of a String > > something like > 'abc > ' > > should just be > 'abc'. > > If I remember that there was a method in class String to something > like this. Is this correct? > Is there a package with additional String convenience methods? you probably want 'abc ' withoutTrailingBlanks You can find that method by evaluating or printing MethodFinder methodFor: { {'abc '} . 'abc' } (a list with arguments {'abc '} and an expected result ( 'abc' )) HTH Best -Tobias _______________________________________________ Beginners mailing list Beginners(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

April 28, 2012

Re: [Pharo-project] Adding hooks for well known events in morphic

by GastÃ³n Dall' Oglio

Hi Guillermo. When you combine these triggers with ads (as in your example), I see an analogy with the model of qt ui, see: http://qt-project.org/doc/qt-4.8/signalsandslots.html In effect: "A signal is emitted when a particular event occurs." -> A Announcement is send when a particular event (trigger) occurs. " Qt's widgets have many predefined signals, but we can always subclass widgets to add our own signals to them" -> Morphic widgets have many predefined triggers, but we can always subclass widgets to add our own triggers to them. "A slot is a function that is called in response to a particular signal. " -> A AnnouncementSubscription is ? that is used in response to a particular announcement. It's a mechanic for decouple between sender and interested in event occurrence. As you surely know Morphic Designer follows basic ideas of the QtDesigner: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki… Look at doc here (I never see code of this project), this approach not use announcement framework, but a signal implementation: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki… Regards. 2012/4/28 Guillermo Polito <guillermopolito(a)gmail.com> > > > On Sat, Apr 28, 2012 at 1:13 PM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > >> Hello. >> >> >> 2012/4/27 Guillermo Polito <guillermopolito(a)gmail.com> >> >>> onShow >>> onDelete >>> onKeyUp >>> onKeyPress >>> onKeyDown >>> onClick >>> onMouseDown >>> onMouseUp >>> onDoubleClick >>> onDragged >>> onDropped >>> onMove? >>> onResize? >>> >>> For all containers >>> onChildAdded >>> onChildRemoved >>> >> >> Maybe this is only way for adding such behaviour in current Morphic >> design. >> > > Starting from a safe point is important when you have a mess :3. > > >> And such approach is most common solution in mainstream UI systems. >> > > I'm for sure influenced by other technologies :). But the changed-updated > mechanism of Morphic makes everything ugly. I just want to make explicit > the events morphs expose to the clients. > > >> But I always feel big smell in such design decisions. >> I am sure more clever solution can be implemented with another Morphic >> design. >> > > What I'd like from a widget is: > - binding values to model properties > - event dispatching on user interaction, so I can register to them > > And containers with nice layouting > > the PluggableXXXMorph have some kind of that stuff modeled, but in the > list of widgets I found, not all of them are PluggableXXX, and there are > some duplicated morphs, and they are spread all over the Morph and Polmorph > package. > > I send the mail to the mailing-list to open a discussion, so I'd like to > know your point of view :). > > Guille >

April 28, 2012

Re: [Pharo-project] Adding hooks for well known events in morphic

by Francisco Garau

What about the stepping behaviour? Is the plan to remove that as well? I've got the hunch that stepping should only be restricted to special worlds. Otherwise you get a lot of behaviour, and complexity, that you don't need in a more traditional UI. My 2 cents... - Francisco On 28 Apr 2012, at 12:44, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Sat, Apr 28, 2012 at 1:13 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > > 2012/4/27 Guillermo Polito <guillermopolito(a)gmail.com> > onShow > onDelete > onKeyUp > onKeyPress > onKeyDown > onClick > onMouseDown > onMouseUp > onDoubleClick > onDragged > onDropped > onMove? > onResize? > > For all containers > onChildAdded > onChildRemoved > > Maybe this is only way for adding such behaviour in current Morphic design. > > Starting from a safe point is important when you have a mess :3. > > And such approach is most common solution in mainstream UI systems. > > I'm for sure influenced by other technologies :). But the changed-updated mechanism of Morphic makes everything ugly. I just want to make explicit the events morphs expose to the clients. > > But I always feel big smell in such design decisions. > I am sure more clever solution can be implemented with another Morphic design. > > What I'd like from a widget is: > - binding values to model properties > - event dispatching on user interaction, so I can register to them > > And containers with nice layouting > > the PluggableXXXMorph have some kind of that stuff modeled, but in the list of widgets I found, not all of them are PluggableXXX, and there are some duplicated morphs, and they are spread all over the Morph and Polmorph package. > > I send the mail to the mailing-list to open a discussion, so I'd like to know your point of view :). > > Guille

April 28, 2012

Re: [Pharo-project] Adding hooks for well known events in morphic

by Guillermo Polito

On Sat, Apr 28, 2012 at 1:13 PM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > Hello. > > > 2012/4/27 Guillermo Polito <guillermopolito(a)gmail.com> > >> onShow >> onDelete >> onKeyUp >> onKeyPress >> onKeyDown >> onClick >> onMouseDown >> onMouseUp >> onDoubleClick >> onDragged >> onDropped >> onMove? >> onResize? >> >> For all containers >> onChildAdded >> onChildRemoved >> > > Maybe this is only way for adding such behaviour in current Morphic design. > Starting from a safe point is important when you have a mess :3. > And such approach is most common solution in mainstream UI systems. > I'm for sure influenced by other technologies :). But the changed-updated mechanism of Morphic makes everything ugly. I just want to make explicit the events morphs expose to the clients. > But I always feel big smell in such design decisions. > I am sure more clever solution can be implemented with another Morphic > design. > What I'd like from a widget is: - binding values to model properties - event dispatching on user interaction, so I can register to them And containers with nice layouting the PluggableXXXMorph have some kind of that stuff modeled, but in the list of widgets I found, not all of them are PluggableXXX, and there are some duplicated morphs, and they are spread all over the Morph and Polmorph package. I send the mail to the mailing-list to open a discussion, so I'd like to know your point of view :). Guille

April 28, 2012

Re: [Pharo-project] Adding hooks for well known events in morphic

by Denis Kudriashov

Hello. 2012/4/27 Guillermo Polito <guillermopolito(a)gmail.com> > onShow > onDelete > onKeyUp > onKeyPress > onKeyDown > onClick > onMouseDown > onMouseUp > onDoubleClick > onDragged > onDropped > onMove? > onResize? > > For all containers > onChildAdded > onChildRemoved > Maybe this is only way for adding such behaviour in current Morphic design. And such approach is most common solution in mainstream UI systems. But I always feel big smell in such design decisions. I am sure more clever solution can be implemented with another Morphic design.

April 28, 2012