- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec new release :)

by Benjamin

It was a real question, and it feels like you overreacted the answer â¦ To me, markdown or pier is a new syntax to learn so I am asking â¦ To me, doing Pier because you do or because you said to is no really an argument. Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown. This was a real question, not a troll ... Ben On 13 Nov 2013, at 19:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > do you really think that I insist of using pier syntax because > A- I want to lose my time > B- this is for my ego? > C- because I'm funny > D- ... > > No seriously? > > If you want to get an answer read the thread that yuri raised a while ago. > Because we already discussed discussed and discussed it. > > I will not write any book in markdown. Now you can try and we see. > > Stef > >> Stef, what is the advantages of writing it in Pier compared to markdown ? >> >> Ben >> > >

Nov. 13, 2013

Re: [Pharo-dev] Instrumenting field accesses with Opal?

by Alexandre Bergel

Thanks for discussing this issue. This is really interesting! Alexandre On Nov 13, 2013, at 12:02 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 13 nov. 2013, at 15:18, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > >> >> >> >> YourClass methods do: [ :method | >> method ast >> forAllNodes: [ :node | node isVariable and: [ node isInstance ] ] >> putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv accessed''' ]; >> installWrapper ]. >> >> >> >> I tried this code but it fails in the latest version of Reflectivity :) > > Neither in old ones, my mistake :) > >> First "RFMetalink class(Object)>>doesNotUnderstand: #expression:" > > Yes it's #fromExpression: > >> then "A variable node on left side of assignment doesn''t accept metalinks" > > Indeed > For iv assignment, you should put metalinks on the assignment node. > So it should be something like that: > > YourClass methods do: [ :method | > method ast > forAllNodes: [ :node | node isVariable and: [node isRead and: [ node isInstance ] ] ] > putAfter: [ RFMetalink fromExpression: 'Transcript crShow: ''iv read''' ]; > forAllNodes: [ :node | node isAssignment and: [ node variable isInstance ] ] > putAfter: [ RFMetalink fromExpression: 'Transcript crShow: ''iv written''' ]; > installWrapper ] > > >> >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 13, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Frank Shearar

On 13 November 2013 16:48, Chris Muller <asqueaker(a)gmail.com> wrote: > I know nothing about Xtreams but, IMO, this obsession with sterility > borders on mental illness. > > "All sort of un-needed complexity?" That's overstating it a bit, > don't you think? > > So you must really feel stressed that ALL Object's, in fact, have a > #name, huh? I admit this seems to push the limits but... > > what's the point of having any kind of different streams at all then? > It's the _differences_ between them that makes composing them useful. > Compression, encryption, filtering, sockets, files, circular, etc. > You think you'll be able to do all that and get away with all of them > having exactly the same API? They don't have the same API. And they shouldn't. And that's Nicolas' whole point. A Stream does not have a name (nor should it - what's the name of the compressed output of an audio stream from your microphone?). A FileStream can extend this API, and that's fine. But keep that out of the Stream API. So Nicolas is arguing that _difference_ should be reflected in the API. File streams have names, but generic streams do not. As it happens, Xtreams takes a very disciplined approach to this. Some streams have positions, and so you can go back. Some can't. This is reflected in the API. This is good. > IMHO working around that, passing extra objects around, sounds more > stressful than letting a stream on a _file_ know its filename.. Mu. Streams have no names. File streams have names. frank >> If it really need it, the application certainly can retrieve the name from a higher level object (a FIleReference, FileDirectory or whatever). > > How does that solution allow uniformity in stream-using code? > > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Yes, a Wrapper would provide the legacy API. >> >> And yes, the name of a stream should better not be part of the API. >> Most stream don't have a name, and adding such API adds all sort of >> un-needed complexity. >> It's an internal detail that can eventually help for reporting error if >> accessible, but nothing more. >> >> If it really need it, the application certainly can retrieve the name from a >> higher level object (a FIleReference, FileDirectory or whatever). >> >> >> 2013/11/13 Chris Muller <asqueaker(a)gmail.com> >>> >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> > It's just a matter of selecting a strategy. I've proposed two: >>> > A) create a wrapper class for legacy Stream compatibility selectors >>> > B) create extensions for Legacy Stream compatibility selectors >>> > My preference goes to A) >>> >>> By wrappers you mean the Xtreams are the innards doing the work and >>> the wrappers providing the legacy API? >>> >>> This would be a great way to test Xtreams. >>> >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: >>> > ...), otherwise we will import all the cruft in Xtream and would go back >>> > to >>> > our starting point... >>> > Once the minimal support written (a few hours should be enough), we >>> > should >>> > gradually switch each every legacy Stream usage -> Xtream. >>> > >>> > An area which require more work is those Streams that have mixed >>> > conventions >>> > (one portion is interpreted as text, another as binary). >>> > In theory that's easy, we just have two streams and they both wrap on a >>> > low >>> > level binary stream, but that means we have to be very cautious with >>> > buffers >>> > and caches. >>> > >>> > Another area of work is usage of ugly selectors like name (we try to >>> > access >>> > the file name from the Stream API, arghh). Those usages are bad and >>> > require >>> > a rewrite. >>> >>> Are you saying a FileStream knowing its #name or #filename is bad? >>> >> >

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by StÃ©phane Ducasse

What is the point of this folder? Do you expect us to write documentation there? Why do you systematically are again pier? especially when I wrote successfully the seaside book with it and so far the only book I saw using markdown are not book? May be I should go back to write in plain latex and like that everybody will be happy. Or I should even do not write any book. Because when I see the amount of energy it takes and after people kill my fun with fucking syntactic issue because I do not use markdown. Stef > I added https://github.com/pharo-project/pharo-documentation > > On 2013-11-13, at 02:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Ben it would be good to do it pier format so that we get html and pdf >> and also to avoid to have documentation spread all over. >> >> Stef >> >> On Nov 12, 2013, at 11:42 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >> >>> Yes it is planned :) >>> >>> The idea is to have it ready for the release of Pharo 3.0 (at last). >>> There is a git repo I just opened[1] where the doc will be :) >>> >>> Every body is free to fork it and to pull-request me :) >>> >>> Ben >>> [1]https://github.com/BenjaminVanRyseghem/Spec_Documentation >>> >>> On 12 Nov 2013, at 23:09, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>>> Is there any new documentation planned ? >>>> >>>> >>>> On Tue, Nov 12, 2013 at 11:42 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >>>> Confirmed and fixed :P >>>> https://pharo.fogbugz.com/default.asp?12153 >>>> >>>> >>>> Ben >>>> >>>> On 12 Nov 2013, at 17:08, Martin Dias <tinchodias(a)gmail.com> wrote: >>>> >>>>> (Checked in Pharo 30567) >>>>> >>>>> On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >>>>>> Thanks Ben. It's neat to have Spec models for tree columns. It was >>>>>> strange to instantiate MorphTreeColumnMorph directly from my Spec >>>>>> model. >>>>>> >>>>>> I found an issue in TreeModel: Only one level of children is shown. >>>>>> Reproduce with: >>>>>> >>>>>> TreeModel new >>>>>> roots: (1 to: 5); >>>>>> childrenBlock: [ :item | 1+item to: 5+item ]; >>>>>> openWithSpec >>>>>> >>>>>> Should I report? >>>>>> >>>>>> MartÃn >>>>>> >>>>>> On Tue, Nov 12, 2013 at 2:59 PM, Benjamin >>>>>> <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >>>>>>> Itâs this one: https://pharo.fogbugz.com/default.asp?12135 >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> On 12 Nov 2013, at 14:49, Martin Dias <tinchodias(a)gmail.com> wrote: >>>>>>> >>>>>>> I forgot to specify: in latest Pharo (30565) >>>>>>> >>>>>>> On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >>>>>>> >>>>>>> I think there is some issue with TreeColumnModel. For example: >>>>>>> >>>>>>> TreeModel exampleWithCustomColumnsAndNodes >>>>>>> >>>>>>> Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" >>>>>>> >>>>>>> Should I report in fogbugz? >>>>>>> >>>>>>> thanks, >>>>>>> MartÃn >>>>>>> >>>>>>> On Tue, Nov 12, 2013 at 2:21 PM, StÃ©phane Ducasse >>>>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>>> >>>>>>> Yes this is what I did for the change sorter. I do not like this DSL like >>>>>>> way of passing block over block over block >>>>>>> over blocks. >>>>>>> >>>>>>> I love blocks but methods are named blocks and I prefer them. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> biut that method can be written: >>>>>>> >>>>>>> aMenu addGroup: (MenuGroupModel new >>>>>>> addItem: (MenuItemModel new >>>>>>> name: 'Browse Full'; >>>>>>> action: [ self browseSelectedObject ]; >>>>>>> shortcut: $b command mac | $b alt win | $b alt unix); >>>>>>> addItem: (MenuItem new >>>>>>> name: 'Browse Class'; >>>>>>> action: [ self browseSelectedObjectClass ])). >>>>>>> >>>>>>> and you do not have to declare variables for that (and is a lot better than >>>>>>> using a block, IMO). >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Nov 12, 2013, at 9:36 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> One can just use an object too. >>>>>>> >>>>>>> Itâs just that otherwise, it pollutes a bit the method with tons of inst >>>>>>> vars >>>>>>> (and then you forget to use them :P) >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> On 12 Nov 2013, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> It is not necessary better, but it saves you from having hundreds of temp >>>>>>> vars :) >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Example: >>>>>>> aMenu addGroup: [ :aGroup | >>>>>>> aGroup addItem: [ :anItem | >>>>>>> anItem name: 'Browse Full'; >>>>>>> action: [ self browseSelectedObject ]; >>>>>>> shortcut: $b command mac | $b alt win | $b alt unix ]. >>>>>>> aGroup addItem: [ :anItem | >>>>>>> anItem name: 'Browse Class'; >>>>>>> action: [ self browseSelectedObjectClass ] ] ]. >>>>>>> >>>>>>> >>>>>>> I do not see the value of passing block to add element to groups >>>>>>> why not the normal way i.e. passing an object. I do not get why executing >>>>>>> a block with an object is better? >>>>>>> >>>>>>> >>>>>>> he, I thought the same :) >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>> >>> >> >

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by StÃ©phane Ducasse

do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ... No seriously? If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it. I will not write any book in markdown. Now you can try and we see. Stef > Stef, what is the advantages of writing it in Pier compared to markdown ? > > Ben >

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by StÃ©phane Ducasse

do it in whatever you want but do not ask me to edit it nor to put it in our book. Stef On Nov 13, 2013, at 1:19 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Stef, what is the advantages of writing it in Pier compared to markdown ? > > Ben >

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by StÃ©phane Ducasse

I give up. Stef On Nov 13, 2013, at 1:19 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Stef, what is the advantages of writing it in Pier compared to markdown ? > > Ben >

Nov. 13, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Nicolas Cellier

Just forgot to add this reductio ad absurdum: I suggest Object ^'John Doe', this is a relatively current name, so it shouldn't hurt. 2013/11/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > > ---------- Forwarded message ---------- > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: 2013/11/13 > Subject: Re: [Pharo-dev] In-memory FileSystem write streams not being > polymorphic > > The long answer is simple: the more responsibility you put in Stream, the > more complexity you get. > The first complexity that I'm speaking of is non-uniformity and random > implementation (or un-implementation) of a set of features. > I mean some streams in the huge hierarchy implement only half of the > contract, but hey, what was the contract exactly? > Ah, yes, there were no contract, just hacks left here and there randomly > and concurrently in a big hierarchy. > I add a new subclass, but don't implement all the features, there are too > many of them, and I don't know them all.. > I add a new feature, but don't implement it in all the classes, there are > too many of them, and I don't know them all. > This procedure invariably ends up with a blob of un-maintanable code, were > two stream would not even agree on upToEnd behavior - I think you remember > it :) > > If the goal is to replicate all the accumulated responsibilities of Squeak > Streams, but with a clarified contract, I think this is a dead end: too > much cruft to support, too many features, too many undefined or not well > defined behaviors to be clarified. > > Xtreams takes the opposite path: concentrate on constructing a common, > simple and uniform API, concerning streams, just basic stream methods. > Some specialized streams then implement some specialized behavior, and you > can compose them (by wrapping) when you need the specific API. > This way, you ain't got to implement/maintain feature A into a few dozen > of classes. > And your brand new SpecialFeatureBStream only has to implement a few well > known behaviours and your Special Feature B. > > The short answer is even more simple : a stream does not have a name, like > a collection does not have a name, because we ain't gonna need it. > If we really need a name, then we'll create a XTNamedReadStream and a > XTNamedWriteStream responding to #name, but I doubt we'll do. > > > 2013/11/13 Chris Muller <ma.chris.m(a)gmail.com> > >> On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> Yes, a Wrapper would provide the legacy API. >>> >>> And yes, the name of a stream should better not be part of the API. >>> Most stream don't have a name, and adding such API adds all sort of >>> un-needed complexity. >>> It's an internal detail that can eventually help for reporting error if >>> accessible, but nothing more. >>> >>> >> I know nothing about Xtreams but, IMO, this obsession with sterility >> borders on mental illness. >> >> "All sort of un-needed complexity?" That's overstating it a bit, don't >> you think? >> >> So you must really feel stressed that ALL Object's, in fact, have a >> #name, huh? I admit this seems to push the limits but... >> >> what's the point of having any kind of different streams at all then? >> It's the _differences_ between them that makes composing them useful. >> Compression, encryption, filtering, sockets, files, circular, etc. You >> think you'll be able to do all that and get away with all of them having >> exactly the same API? >> >> IMHO working around that, passing extra objects around, sounds more >> stressful than letting a stream on a _file_ know its filename.. >> >> If it really need it, the application certainly can retrieve the name >>> from a higher level object (a FIleReference, FileDirectory or whatever). >>> >> >> How does that solution allow uniformity in stream-using code? >> >> >> >> >> >> >>> >>> >>> 2013/11/13 Chris Muller <asqueaker(a)gmail.com> >>> >>>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> > It's just a matter of selecting a strategy. I've proposed two: >>>> > A) create a wrapper class for legacy Stream compatibility selectors >>>> > B) create extensions for Legacy Stream compatibility selectors >>>> > My preference goes to A) >>>> >>>> By wrappers you mean the Xtreams are the innards doing the work and >>>> the wrappers providing the legacy API? >>>> >>>> This would be a great way to test Xtreams. >>>> >>>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek >>>> upTo: >>>> > ...), otherwise we will import all the cruft in Xtream and would go >>>> back to >>>> > our starting point... >>>> > Once the minimal support written (a few hours should be enough), we >>>> should >>>> > gradually switch each every legacy Stream usage -> Xtream. >>>> > >>>> > An area which require more work is those Streams that have mixed >>>> conventions >>>> > (one portion is interpreted as text, another as binary). >>>> > In theory that's easy, we just have two streams and they both wrap on >>>> a low >>>> > level binary stream, but that means we have to be very cautious with >>>> buffers >>>> > and caches. >>>> > >>>> > Another area of work is usage of ugly selectors like name (we try to >>>> access >>>> > the file name from the Stream API, arghh). Those usages are bad and >>>> require >>>> > a rewrite. >>>> >>>> Are you saying a FileStream knowing its #name or #filename is bad? >>>> >>>> >>> >> > >

Nov. 13, 2013

Fwd: In-memory FileSystem write streams not being polymorphic

by Nicolas Cellier

---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> Date: 2013/11/13 Subject: Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic The long answer is simple: the more responsibility you put in Stream, the more complexity you get. The first complexity that I'm speaking of is non-uniformity and random implementation (or un-implementation) of a set of features. I mean some streams in the huge hierarchy implement only half of the contract, but hey, what was the contract exactly? Ah, yes, there were no contract, just hacks left here and there randomly and concurrently in a big hierarchy. I add a new subclass, but don't implement all the features, there are too many of them, and I don't know them all.. I add a new feature, but don't implement it in all the classes, there are too many of them, and I don't know them all. This procedure invariably ends up with a blob of un-maintanable code, were two stream would not even agree on upToEnd behavior - I think you remember it :) If the goal is to replicate all the accumulated responsibilities of Squeak Streams, but with a clarified contract, I think this is a dead end: too much cruft to support, too many features, too many undefined or not well defined behaviors to be clarified. Xtreams takes the opposite path: concentrate on constructing a common, simple and uniform API, concerning streams, just basic stream methods. Some specialized streams then implement some specialized behavior, and you can compose them (by wrapping) when you need the specific API. This way, you ain't got to implement/maintain feature A into a few dozen of classes. And your brand new SpecialFeatureBStream only has to implement a few well known behaviours and your Special Feature B. The short answer is even more simple : a stream does not have a name, like a collection does not have a name, because we ain't gonna need it. If we really need a name, then we'll create a XTNamedReadStream and a XTNamedWriteStream responding to #name, but I doubt we'll do. 2013/11/13 Chris Muller <ma.chris.m(a)gmail.com> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Yes, a Wrapper would provide the legacy API. >> >> And yes, the name of a stream should better not be part of the API. >> Most stream don't have a name, and adding such API adds all sort of >> un-needed complexity. >> It's an internal detail that can eventually help for reporting error if >> accessible, but nothing more. >> >> > I know nothing about Xtreams but, IMO, this obsession with sterility > borders on mental illness. > > "All sort of un-needed complexity?" That's overstating it a bit, don't > you think? > > So you must really feel stressed that ALL Object's, in fact, have a #name, > huh? I admit this seems to push the limits but... > > what's the point of having any kind of different streams at all then? > It's the _differences_ between them that makes composing them useful. > Compression, encryption, filtering, sockets, files, circular, etc. You > think you'll be able to do all that and get away with all of them having > exactly the same API? > > IMHO working around that, passing extra objects around, sounds more > stressful than letting a stream on a _file_ know its filename.. > > If it really need it, the application certainly can retrieve the name from >> a higher level object (a FIleReference, FileDirectory or whatever). >> > > How does that solution allow uniformity in stream-using code? > > > > > > >> >> >> 2013/11/13 Chris Muller <asqueaker(a)gmail.com> >> >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> > It's just a matter of selecting a strategy. I've proposed two: >>> > A) create a wrapper class for legacy Stream compatibility selectors >>> > B) create extensions for Legacy Stream compatibility selectors >>> > My preference goes to A) >>> >>> By wrappers you mean the Xtreams are the innards doing the work and >>> the wrappers providing the legacy API? >>> >>> This would be a great way to test Xtreams. >>> >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek >>> upTo: >>> > ...), otherwise we will import all the cruft in Xtream and would go >>> back to >>> > our starting point... >>> > Once the minimal support written (a few hours should be enough), we >>> should >>> > gradually switch each every legacy Stream usage -> Xtream. >>> > >>> > An area which require more work is those Streams that have mixed >>> conventions >>> > (one portion is interpreted as text, another as binary). >>> > In theory that's easy, we just have two streams and they both wrap on >>> a low >>> > level binary stream, but that means we have to be very cautious with >>> buffers >>> > and caches. >>> > >>> > Another area of work is usage of ugly selectors like name (we try to >>> access >>> > the file name from the Stream API, arghh). Those usages are bad and >>> require >>> > a rewrite. >>> >>> Are you saying a FileStream knowing its #name or #filename is bad? >>> >>> >> >

Nov. 13, 2013

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

by Sean P. DeNigris

Igor Stasenko wrote > PaError Pa_OpenDefaultStream(NBExternalAddress * stream ... ) > then your call site will look like following: > streamHandle := NBExternalAddress new. Okay, one step closer. I somewhat randomly guessed to use NBExternalAddress, but didn't have the correct thing in the signature... Igor Stasenko wrote > But hold on, next thing you will stuck with is callback ... hehe :) > ... > for that, again you can just change the function signature and... > put nil. (yes, nil literal) So you're saying the signature would become: nbCall: #(PaError Pa_OpenDefaultStream(NBExternalAddress * stream, ... ulong framesPerBuffer, nil, void * userData)) I made the changes as I understood them, but I'm getting a "generic failure" when I call Pa_OpenDefaultStream. I uploaded the latest changes to the repo... ----- Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 13, 2013