- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [NB] NativeBoost and optCoerceNilToNull

by Igor Stasenko

On 15 November 2014 15:53, Max Leske <maxleske(a)gmail.com> wrote: > Once again Iâm struggling with NativeBoost. Iâm trying to use > optCoerceNilToNull with this function: > > ^self call: #(LGitReturnCodeEnum git_commit_create( > LGitId * theCommitId, > LGitRepository repo, > String update_ref, > LGitSignature * theAuthor, > LGitSignature * theCommitter, > String message_encoding, > String theMessage, > LGitTree theTree, > int parent_count, > LGitCommit * parentsPointer)) options: #( optCoerceNilToNull ) > > The last argument can be NULL, per documentation, (no parents). > LGitCommit is a subclass of NBExternalObject and apparently > NBExternalObjctType>>pushAsPointer: does *not* use the optCoerceNilToNull > option (the super implementation in NBExternalType>>pushAsPointer: however > does). The upshot of course is that the call fails with âan instance of > LGitCommit expectedâ. > > My questions: > - The documentation says: > > > "#optCoerceNilToNull" > "passing nil as a pointer-type argument, converts it to C NULL â > > but apparently this doesnât apply to every pointer type. Should the > documentation be updated? > - Why does NBExternlObjectType not use optCoerceNilToNull? I donât want to > use tricks to pass null if I donât have to. > perhaps because it is not there? :) So, lets add it. - Related: there are instances where even non-pointer arguments are allowed > to be NULL. Why does optCoerceNilToNull only work for pointer types? > > like what? Suppose the argument type is a structure, e.g "struct foo bar", that is non-pointer type. What in this case the NULL value for the structure? > Igor! Help! :) > > Cheers, > Max > > -- Best regards, Igor Stasenko.

Nov. 15, 2014

Re: [Pharo-dev] [Bloc] Getting involved

by kilon alios

is there a place where we can check the code and see what Bloc is all about ? On Sat, Nov 15, 2014 at 9:59 PM, stepharo <stepharo(a)free.fr> wrote: > > On 11/11/14 00:43, Santiago Bragagnolo wrote: > >> Hi Guys, (Alan and Steph punctually) I want to comment I am getting >> involved with Bloc, since i need to draw several things and i need an >> Athens canvas. >> >> I am checking if it is the best tool for my needs. In any case I am doing >> some contributions that i would like to commit and to share. Actually i am >> working on draft a window, a tool bar, a button based on images and >> animations. >> >> Then, there is any mailing list for Bloc? How is the push-request cycle? >> > > Alain told me that you should design a widget and based on the quality he > will let you commit :) > I'm confident. So let us know which widget you want to work on. > > Stef > >> >> Thanks :). >> >> Santiago. >> >> > >

Nov. 15, 2014

Re: [Pharo-dev] How to refresh the pharo window manually

by kilon alios

I tried to search for update method , could not find anything meaningful , there like a gazillion update methods. Another problem is how to get hold of WorldMorph of DisplayScreen or whatever class is responsible for the update. Do I access through the Smalltalk global ? How ? On Sat, Nov 15, 2014 at 9:50 PM, stepharo <stepharo(a)free.fr> wrote: > did you try update? > > > On 15/11/14 13:26, kilon alios wrote: > >> Hello guys I am making a theme manager and I have observed that when I >> choose a background color for pharo windows it does not update properly. >> How I can force the whole pharo window to update ? I have found >> DisplayScreen and WorldMorph but no idea how to use them. >> > > >

Nov. 15, 2014

Re: [Pharo-dev] Who broke my System Preferences ?

by stepharo

The theme design is ot good but getting a good one is difficult. I did some prototype to get a feel of the work to be done but this is still unclear to me. I want to see how we could do that with Bloc. Stef On 10/11/14 16:00, kilon alios wrote: > no worries I would not even dream to blame you and yes I completely > agree that you did not need to wait for a review ,after all its not > that much of a big deal to ping the mailing list as I did and you > fixing it at your own pace , I can always use an older build at any time. > > The Theme classes is kinda strange, I think that Pharo needs a > standard on theme support and that standard must be deeply rooted > inside Morphic so that each morph implements its own theme support. Of > course for that the community will need to sit down and agree what > that standard must be or else you will see theme classes popping > around like mushrooms. > > On Mon, Nov 10, 2014 at 3:46 PM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > > On 10 Nov 2014, at 14:18, kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> wrote: > > > > looks like latest Pharo 4 40363 broke System Preferences > clicking on Appearance gives me this > > > > Oh, I missed call in fontSizeRowâ¦ I thought I tested it. I will > fix it... > (Hint: I always wait for people to review my changesâ¦ but that > does not happen very often) > > > Marcus > >

Nov. 15, 2014

Re: [Pharo-dev] Who broke my System Preferences ?

by stepharo

> yeaâ¦ I wanted to normally move the whole class somewhere else, but then I stopped and just committed > what I had. > > I did the #theme thing because it looks so ugly to have #theme implemented everywhere > (we have 33 implementors! 33!!) > and I just saw two senders in this classâ¦ > > All the Theme stuff is so uglyâ¦ Yes but let it like that for the moment. I would prefer that you push OPAL because we need a strong OPAL + slot + reflectivity for the future. Stef > >> May be changing >> theme >> UIManager default theme >> >> by >> theme >> ^ Smalltalk ui theme >> >> is better but not expanding all the self theme with this expression >> Because we do not know in the future how the theme will be implemented in the future. >> >> Stef >> >> >> On 10/11/14 14:46, Marcus Denker wrote: >>>> On 10 Nov 2014, at 14:18, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>> looks like latest Pharo 4 40363 broke System Preferences clicking on Appearance gives me this >>>> >>> Oh, I missed call in fontSizeRowâ¦ I thought I tested it. I will fix it... >>> (Hint: I always wait for people to review my changesâ¦ but that does not happen very often) >>> >>> >>> Marcus >>> >>> >> > >

Nov. 15, 2014

Re: [Pharo-dev] [Bloc] Getting involved

by stepharo

On 11/11/14 00:43, Santiago Bragagnolo wrote: > Hi Guys, (Alan and Steph punctually) I want to comment I am getting > involved with Bloc, since i need to draw several things and i need an > Athens canvas. > > I am checking if it is the best tool for my needs. In any case I am > doing some contributions that i would like to commit and to share. > Actually i am working on draft a window, a tool bar, a button based on > images and animations. > > Then, there is any mailing list for Bloc? How is the push-request cycle? Alain told me that you should design a widget and based on the quality he will let you commit :) I'm confident. So let us know which widget you want to work on. Stef > > Thanks :). > > Santiago. >

Nov. 15, 2014

Re: [Pharo-dev] cross platform issue with versionner in pharo 3.0 - want a slice?

by stepharo

> Hey - > > I'm thinking about making a slice to that versionner doesn't use Symbols for class names when creating baselines. The problem is that on GemStone symbols and strings don't compare as equal, so looking up a class in a repo fails. ouch we were not aware of that > > > Is that slice something that is generally interesting ? probably, I will let christophe reply. > Is it already fixed in Pharo 4? I do not think so > > > Thanks > > Paul >

Nov. 15, 2014

Re: [Pharo-dev] [NB] Undocumented NativeBoost options

by stepharo

On 15/11/14 12:37, Max Leske wrote: > I got a bit frustrated and ended up searching the source for â[\w]opt[[:upper]]â to find all NativeBoost options. Some of those options are in fact undocumented: > > optMayGC > optProxyLabels > optCdecl > optReturnNullAsNil > optStdcall > optNonMovable > optReserveCallgateSpace > optDebug > optNoAlignment > optEmitCall > optNoCleanup > optCheckFailOnEveryArgument > optStringOrNull > WinUnicode > > NBFFICallout>>defaultOptions documents most options but refers to NBFFICallout>>allOptions, wich does not exist. Most of the above options can be considered internal, I guess, but the one option I needed (âoptStringOrNullâ) isnât documented anywhere. I had to step through the execution to find out why my function call wasnât working (because I was trying to use âoptCoerceNilToNullâ and didnât know that strings need a special option). > > Iâd be very thankful if these options would be included in the documentation. Which documentation? There is one? And yes this pisses me off. > > Note: âWinUnicodeâ is used by the Windows code in a couple of places, even though the option name is not valid, according to NBNativeCodeGen>>parseOptions: > > Cheers, > Max >

Nov. 15, 2014

Re: [Pharo-dev] How to refresh the pharo window manually

by stepharo

did you try update? On 15/11/14 13:26, kilon alios wrote: > Hello guys I am making a theme manager and I have observed that when I > choose a background color for pharo windows it does not update > properly. How I can force the whole pharo window to update ? I have > found DisplayScreen and WorldMorph but no idea how to use them.

Nov. 15, 2014

Re: [Pharo-dev] ValueHolder analysis

by stepharo

Hi Henrik Thanks for your point :) I agree with you. Esteban prefered the current solution because of law of demeter but I do not think that this is good. So we will rewrite all these methods. If you want to help you are welcome. Stef On 14/11/14 16:25, Henrik Johansen wrote: >> On 14 Nov 2014, at 12:01 , stepharo <stepharo(a)free.fr> wrote: >> >> I checked a bit deeper >> >> >> Nautilus is not implemented in Spec. But senders and implementors are and they also leak memory. Around 400 Announcers after each >> opening and closing. >> >> Now >> >> whenChangedDo: aBlock >> >> | block | >> block := [:announcement :ann | aBlock cull: announcement newValue cull: announcement oldValue cull: announcement cull: ann ]. >> announcer when: ValueChanged do: block >> >> can also be part of the cause of some of our problems. >> >> There are 146 senders and many of them could just be replaced by whenChanged:send:to: and whenChanged:send:to:with: >> >> >> Finally we were discussing with igor about the general API of spec model: We are thinking that the following patterns >> are bloating the interface for an not obvious gain. >> >> whenWindowChanged: aBlock >> >> window whenChangedDo: aBlock >> >> >> whenShortcutsChanged: aBlock >> <api: #event> >> "Set a block to value when the shortcuts block has changed" >> >> additionalKeyBindings whenChangedDo: aBlock > I'd argue the window and additionalKeyBindings' whenChangedDo: implementations are unnecessary bloat as well. > Why on earth would you limit yourself to a an API where you have to use seperate methods to register for every single announcement type? > > To me, > myObject additionalKeyBindings when: ValueChanged do: aBlock > is just as easy, if not easier to read compared to > myObject whenShortCutsChanged: [] > > Not to mention, it easily lets you do unsubscription when you expect not to outlive the source (through the 3rd block parameter, whose *main purpose for even being there* is enabling easy unsubscription), rather than discarding it during useless indirection and leaving the task harder to do later on? > > Cheers, > Henry >

Nov. 15, 2014