- Pharo-dev - lists.pharo.org

Re: [Pharo-project] TextLint questions and feedback

by Mariano Martinez Peck

Ok....I am using TextLint for all my papers now :) Few more things: 1) It would be awesome a rule that detects duplication of connectors in a near area. For example, if I use connectors like "However, Nevertheless, Hence, On the contrary, One the other hand, etc..." it would be nice a rule that detects that you already use the same connector some lines before/after a specific one... 2) I don't understand the rule: "Do not join sentences with commas ". Is this working well ? I have these phrases for example: - To support automatic memory management, most object oriented systems are based on garbage collectors (GC) \cite{Jone96a}. - In class-based object-oriented languages, information about class usage is needed. - For this we use Distribution Map, a visualization showing spread and focus of properties across systems. I think the "comma" there are correct. Maybe I am wrong. Thanks mariano On Thu, Sep 2, 2010 at 9:34 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Thu, Sep 2, 2010 at 9:20 PM, Jorge Ressia <jorge.ressia(a)gmail.com>wrote: > >> Hi, >> >> So >> > > I have just sent you by private email the .tex. > > >> >> 1) Could not reproduce >> >> > Should be reproducable with my .tex > > >> 2) >> 2.a) Working on that >> 2.b) Could not reproduce >> >> > me neither. Did you check if you are using a Set for the collection? > > >> 3) It is hard to achieve, we still have it in the todo list. >> > > Yes, I imagined ;) > > >> >> 4) Could not reproduce >> >> > Should be reproducable with my .tex > > >> 5) Fixed >> >> 6) Checking >> >> > excellent :) > > >> It would be cool if we could have a look at your file so we can have a >> better way of debugging these issues. >> >> > Done :) > > >> Thanks >> >> >> >> On Thu, Sep 2, 2010 at 6:54 PM, Jorge Ressia <jorge.ressia(a)gmail.com> >> wrote: >> > Hi Mariano, >> > >> > Thanks for trying TextLint out and for the feedback. >> > >> > We will look into your issues and try to figure out a solution. >> > >> > If you have a draft of your text with these occurrences please send it >> > to us. You can remove the text that is not relevant. >> > >> > Cheers, >> > >> > Jorge >> > >> > 2010/9/2 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> Hi. First, please let me know if this is the correct place to talk >> about >> >> TextLint. I've just used for one paper I am writing and I have some >> >> questions/feedback. I am using the one click image. >> >> >> >> 1) The "An Rule" could be a little more smart and detects commands. For >> >> example, in my latex I have " an \emph{inner object}" and that was >> detected >> >> by the rule, althought I shouldn't. So...detecting the slash and ignore >> what >> >> it surrounded by {} would be nice for this rule. >> >> >> >> 2) When I edit the code inside TextLint and I save it, two bad things >> >> happens: >> >> 2.a) I lost focus of the text, as it moves when it finishing >> saving. >> >> The line I edited goes to the end of the text area. It would be great >> if >> >> nothing moves nor to loose focus when saving. >> >> 2.b) sometimes (I cannot reproduce) the order of the rules >> >> changes...and this is not good because I was going in order, one by >> one, and >> >> suddenly they are re-ordered. Maybe you are using a Set for that? using >> a >> >> simple OrderedCollection could help. >> >> >> >> 3) If you edit the text (and it differs in the amount of characters), >> and DO >> >> NOT save it, the following color highlighting are moved. It seems you >> keep >> >> the position in the file, and until it is saved, rules results are >> pointing >> >> to "unupdated" file. Of course, when I save the file, they are correct. >> I >> >> guess this is from a performance point of view, but maybe you have a >> little >> >> hack to do and make it better. >> >> >> >> 4) The rule "no white space before punctuation mark" showed me things I >> >> didn't understand. For example, it says this line there is a "," >> (comma) : >> >> >> >> \item[ Shared object ] In the case of the \emph{shared objects}, it >> is >> >> almost the same as in the \emph{inner objects}. An ..... >> > >> > >> >> 5) Rules comments clearer. For example, when you say "Avoid using a >> lot, it >> >> weakens the sentence" It would be better to put "Avoid using "a lot", >> it >> >> weakens the sentence" >> >> or "Avoid using *a lot*, it weakens the sentence" >> >> or something to clearly mark the words not to use. Because sometimes >> the >> >> words are confused with the context. Or this one: >> >> >> >> "After an only words beginning with a vowel are allowed. " >> >> should be "After "an" only words beginning with a vowel are allowed." >> >> >> >> 6) For the rules of long sentences/paragraph it would be nice to ignore >> >> \fotenote{} >> >> >> >> 7) Maybe this link is of interest for you: >> >> >> http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words… >> >> >> >> Apart from all these things, the tool is very useful and I like it. >> >> >> >> thanks >> >> >> >> Mariano >> >> >> >> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > >> > >> > -- >> > Jorge Ressia >> > www.jorgeressia.com >> > >> >> >> >> -- >> Jorge Ressia >> www.jorgeressia.com >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Henrik Johansen

On Sep 23, 2010, at 4:03 07PM, StÃ©phane Ducasse wrote: > igor > > May be a layer for people that are not fluent with assembly would help. > Make the path easy from FFI writing. It is already, RTM :) http://code.google.com/p/nativeboost/wiki/NBFnSpecParser > Get some patterns so that people can learn by following patterns. > > Stef Cheers, Henry

Sept. 23, 2010

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?

by Henrik Johansen

On Sep 23, 2010, at 9:40 42AM, Alain Plantec wrote: > Le 23/09/2010 09:17, StÃ©phane Ducasse a Ã©crit : >> Yes >> I think that we should just get better at packaging/loading.... >> But this package is important so it should be a supported package. >> >> Stef >> >> > Concerning the size issue: > On a fresh image: after a cleanUpForRelease -> 13.4 Mo > > Then, I've load the full dejaVu font and I've removed the old accuny one, > also removed old dejaVu (the current one with 3 sizes), > cleaned StrikeFont class > then cleanUpForRelease -> 14.1 Mo > > In this image, only one dejaVu font with all sizes, so that standard and demo mode are working. > Of course we can also remove small sizes (maybe 5, 6 and 7) to decrease the size more. > > Cheers > Alain Sounds like a plan, I feel the StrikeFont port from Cuis is new robust enough now to drop accuny completely. Personally I find 7 a good size for tooltips/buttons, haven't used the even smaller sizes. The package should be updated to provide proper derived fonts for Bold Italic though. Also, is there a specific reason bitmaps for Italic underlined is included for size 12, and no others? Cheers, Henry

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by StÃ©phane Ducasse

igor May be a layer for people that are not fluent with assembly would help. Make the path easy from FFI writing. Get some patterns so that people can learn by following patterns. Stef On Sep 23, 2010, at 3:07 PM, Igor Stasenko wrote: > On 23 September 2010 06:11, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The examples that make sense depend on what NativeBoost wants to be when it grows up. Is it a full competitor to FFI and/or Alien? If so, then it would be nice to see a rich set of calls to functions with different parameter types; ideally it would be in the form of something useful that gets added to Pharo using NativeBoost. That does a couple of things, providing both proof of concept and examples in one shot. >> > One major 'proof of concept' kinda, is NBOpenGL package, which > provides a full OpenGL bindings by using NativeBoost :) > But sure thing, basic examples is a must. That's why i asked you , > whant you wanna see. > > I have no idea, what can be userful to pharoers , since i can do > anything and its completely trivial for me to implement, > as an author of this project ;) > So, without some feedback, i have no idea, if something in my code > looks confusing, or hard to use and needs > deeper explanation(s) and examples. > >> With tongue firmly in cheek, looking at your indexing example, my stack might pop before the machine's :) However, it looks like it should settle down quickly enough, and things like that go on in the vm all the time; you are arguably just brining it into the image. > > Indeed. Arguably. You putting your code into an image, instead of extra plugin. > So, once your code is debugged and works well, you are done, and don't > have to worry with shipping a custom VM/plugin > with your product. The development and deployment of new primitives is > much faster if you using NB. > >> Where would #readDoubleFrom: be in the class hiearchy? One of the reasons I asked about indexing an external array is that FFI is not good at such things. If you can provide ways to copy, fill, etc. blocks of memory and do it quickly, you gain ground, assuming you want to compete with FFI. > > In this particular example, you can do a usual way - make a > DoubleArray class, which is a subclass > of ByteArray , then implement #at: and #at:put: using nativeboost. > Implement various stuff to fully cover Collection protocol, > implement any extra stuff like blob operations (multiplication, > addition etc) if you want. > > And you don't have to compete with FFI, since you can implement all > primitives in NativeBoost without using any external functions. > You can use any kind of optimizations in native code, which are not > available in C, like using SSE/SIMD instructions etc. > Even more, you can detect a CPU type, and depending on that, generate > a most efficient code for your little class/library. > >> >> Do callbacks, and you gain a lot of ground. Make calls on separate threads, and you gain a LOT of ground. That assumes that you can make it simple enough for a mildly above-average C programmer to understand how to use and ideally extend it. I will look at your example package on Squeak Source. > > Callbacks is there. See NBFFICallbackTests>>benchQSort for example. > >> >> One thing that drives me nuts with the Linux vm is that it looks for things where it wants to look, and gives no feedback about what it tried to do or even that it failed (except that handle is still zero). Your callout pragmas take a module name; is there any way to see inside of that or to provide a full path to the library? It is nice to be able to confirm loading of a library w/o having to call something, since there won't always be something "safe" (free of side effects) to call as a test. >> > > Wait, there is no callout pragmas.. > All stuff which starts from > > ^ NBFFICallout > cdecl: #( double ( void * address) ) ... > > is smalltalk code, and you can debug it and see what it does, and how > it loading a module and retrieving an external function > pointer from it. > You can customize this procedure in any way you want (by subclassing > NBFFICallout), you can even customize the way how you making a call. > > For instance, in NBOpenGL, a generated code does not making a direct > call to previously discovered function address. > It using an sub-instance of NBOpenGLAPIBase, which is a > variable-sized object, holding a function pointers, > and it reads a corresponding pointer from this object, and only then > making a call. > > So, there are plenty various tricks which can be done without much > hassle. You just need to step away from rigid patterns, > imposed by C compler, linker and all stuff around that, and you will > see, that you can do miracles in smalltalk + native code :) > >> At the risk of seeming difficult, everything is academic until we have a Linux plugin or at least can build same. Alien has that problem. > > I'm working on that. > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Wednesday, September 22, 2010 10:05 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] NativeBoost examples (was: Re: DoubleArray) >> >> On 23 September 2010 02:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Sig, >>> >>> Fair enough :) The most recent thing I recall on NativeBoost is Stef asking for what I assume must be a Mac plugin; I thought Linux would be left out too, but it appears not, though it is not in my current vm. Beyond some list traffic, I found this: >>> >> >> The work for supporting Linux and Mac is in progress. >> >>> http://code.google.com/p/nativeboost/wiki/NativeBoost >>> >>> Is there other documentation somewhere? Build instructions? >> >> You can find all existing documentation, installation instructions on >> wiki pages at the above site. There is no other place for it. >> http://code.google.com/p/nativeboost/wiki/Installation - installation >> instructions. >> >>> You have a block copy, which is good. What about indexing, such as getting floats or doubles out of external memory? >> >> This is just a piece of cake. ;) >> >> readDoubleFrom: address >> " This method loads the double from given external address. >> an address can be an instance of NBExternalAddress, or >> simple ByteArray with at least 8 bytes long, which holds a double >> floating value" >> >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> >> "We are using a pseudo-function prototype and supplying own assembler code, >> instead of making a call to external function. >> In given example, an address argument , after coercion is pushed on stack. " >> >> ^ NBFFICallout >> >> cdecl: #( double ( void * address) ) >> " A pseudo-function takes 1 argument, and returns double value. >> Under cdecl call convention, all floating point return types is >> returned in fp(0) CPU register" >> >> emitCall: [:gen | | asm | >> asm := gen asm. >> >> "Here , we expecting that an address value is already pushed on stack" >> >> asm pop: asm EAX; "load an address value into EAX register by >> popping a stack" >> fld: (asm EAX ptr64). "load a floating point value from memory, at >> base address, held in EAX register into fp(0) register, >> we are using #ptr64, to indicate that memory operand size is 64bits long" >> >> " return value set, we are done. A code generator will take care >> for emitting code, which converts >> a double floating point value into smalltalk object. " >> ] >> >> I just uploaded this example and also how to write doubles from/to memory. >> See at SqS/NativeBoost - NativeBoost-Examples package, class NBBasicExamples. >> >>> I am very comfortable adding functions to a library for integer and float/double calculations on "large" arrays and calling them via FFI; plugins are another story. Are there examples to follow? >> >> Tell me, what examples you would like to see. I will gladly provide them. >> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >>> Sent: Wednesday, September 22, 2010 6:20 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] DoubleArray >>> >>> On 23 September 2010 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>> Henry, >>>> >>>> I have been getting away with #doubleAt: and #doubleAt:put:, and otherwise doing pretty much what you said, though I just use a byte array to hold the data. It seems to work; for FFI, I end up passing void pointers instead of double pointers, which I don't like doing. >>>> >>>> Your point about using ordinary arrays makes sense to a point, though even w/o external interfacing, there is still a use for DoubleArray just as there is a use for String vs. an array of characters. >>>> >>> >>> The main reason, why they are not here, that VM needs an additional >>> set of primitives, which working with them. >>> >>> <sellsman hat on> >>> I can only say that with NativeBoost, you could be able to implement >>> it quite easily in image and ship it in image, >>> without a need to change VM or use external plugin. >>> <sellsman hat off> >>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] >>>> Sent: Wednesday, September 22, 2010 5:23 PM >>>> To: pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] DoubleArray >>>> >>>> On 22.09.2010 23:09, Schwab,Wilhelm K wrote: >>>>> Squeak, deliberately, does not have a double array class. Is that because there is some horrible reason it can't work, or because it won't work on certain platforms? >>>> If the goal is to pass it as a parameter to an external function, one >>>> way would be to subclass WordArray, storing(and reading) each Float in >>>> two elements, and have the endianness decided by Smalltalk endianness. >>>> Probably want a startUp method for the class to swap instances >>>> endianness if the platform has changed as well. >>>>> Put another way, should we add such a class, if only via an external heap or whatever would be needed to make it reliable? >>>>> >>>>> Bill >>>> More likely because no one has actually had a need for one. >>>> It's definitely not _needed_ in base, where normal arrays of floats >>>> would do the same job just as well, if not better. >>>> IMHO, if someone makes one, it so should probably be part of a package >>>> related to external interfacing. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010

Re: [Pharo-project] decompiledSource

by StÃ©phane Ducasse

herve if the suggestion of henrik does not help you let us know what kind of crazy stuff you are doing :) Stef On Sep 23, 2010, at 2:15 PM, Henrik Johansen wrote: > > On Sep 23, 2010, at 1:35 18PM, Herve Verjus wrote: > >> Hello All, >> >> I would like to port some VisualWorks code into Pharo. The VW current project code uses VW Kernel.decompiledSource that does not seem to be implemented in Pharo...Is there a Pharo method that does the same...Is there someone with an idea ? >> >> Thank you... >> >> Herve > If you mean CompiledBlock/CompiledCode #decompiledSource, I think the equivalent in Pharo would be BlockClosure / CompiledMethod #decompile > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?

by Alain Plantec

Accuny was not fully removed in my previous try (was still referenced by TextConstants). After deeper cleaning and loading of the dejaVu font without the 5, 6 and 7 sizes -> 14.0 Mo. The size was of 13.2 Mo before the cleaning, so, I guess that the price is of 0.8 Mo. Here is what I've done: ------- Before: World removeAllMorphs. StrikeFont cleanUp. ScriptLoader new cleanUpForRelease. -> 13.2 Mo Then: World removeAllMorphs. StrikeFont cleanUp. DejaVuHolder cleanUpForRelease. StandardFonts setFontsFromSpec: #( #(#defaultFont: 'Bitmap DejaVu' 9 ) #(#codeFont: 'Bitmap DejaVu' 9 ) #(#listFont: 'Bitmap DejaVu' 9 ) #(#menuFont: 'Bitmap DejaVu' 9 ) #(#windowTitleFont: 'Bitmap DejaVu' 12 ) #(#balloonFont: 'Bitmap DejaVu' 10 ) #(#haloFont: 'Bitmap DejaVu' 10 ) #(#buttonFont: 'Bitmap DejaVu' 9 ) ). StrikeFont class removeCategory: #'*Graphics-Resources'. TextConstants removeKey: #Accuny. TextConstants removeKey: #'Bitmap DejaVu Sans'. TextConstants at: #DefaultFixedTextStyle put: (TextConstants at: #'Bitmap DejaVu'). TextConstants at: #DefaultMultiStyle put: (TextConstants at: #'Bitmap DejaVu'). StrikeFont cleanUp. ScriptLoader new cleanUpForRelease. SmalltalkImage current garbageCollectMost. ------ After that, there was still an old text style referenced by the ParagraphEditor UndoParagraph class variable. I've cleaned it by setting UndoParagraph to nil from an inspector. Cheers Alain Le 23/09/2010 09:40, Alain Plantec a Ã©crit : > Le 23/09/2010 09:17, StÃ©phane Ducasse a Ã©crit : >> Yes >> I think that we should just get better at packaging/loading.... >> But this package is important so it should be a supported package. >> >> Stef >> > Concerning the size issue: > On a fresh image: after a cleanUpForRelease -> 13.4 Mo > > Then, I've load the full dejaVu font and I've removed the old accuny one, > also removed old dejaVu (the current one with 3 sizes), > cleaned StrikeFont class > then cleanUpForRelease -> 14.1 Mo > > In this image, only one dejaVu font with all sizes, so that standard > and demo mode are working. > Of course we can also remove small sizes (maybe 5, 6 and 7) to > decrease the size more. > > Cheers > Alain > >

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Igor Stasenko

On 23 September 2010 06:11, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > The examples that make sense depend on what NativeBoost wants to be when it grows up. Â Is it a full competitor to FFI and/or Alien? Â If so, then it would be nice to see a rich set of calls to functions with different parameter types; ideally it would be in the form of something useful that gets added to Pharo using NativeBoost. Â That does a couple of things, providing both proof of concept and examples in one shot. > One major 'proof of concept' kinda, is NBOpenGL package, which provides a full OpenGL bindings by using NativeBoost :) But sure thing, basic examples is a must. That's why i asked you , whant you wanna see. I have no idea, what can be userful to pharoers , since i can do anything and its completely trivial for me to implement, as an author of this project ;) So, without some feedback, i have no idea, if something in my code looks confusing, or hard to use and needs deeper explanation(s) and examples. > With tongue firmly in cheek, looking at your indexing example, my stack might pop before the machine's Â :) Â However, it looks like it should settle down quickly enough, and things like that go on in the vm all the time; you are arguably just brining it into the image. Indeed. Arguably. You putting your code into an image, instead of extra plugin. So, once your code is debugged and works well, you are done, and don't have to worry with shipping a custom VM/plugin with your product. The development and deployment of new primitives is much faster if you using NB. > Where would #readDoubleFrom: be in the class hiearchy? Â One of the reasons I asked about indexing an external array is that FFI is not good at such things. Â If you can provide ways to copy, fill, etc. blocks of memory and do it quickly, you gain ground, assuming you want to compete with FFI. In this particular example, you can do a usual way - make a DoubleArray class, which is a subclass of ByteArray , then implement #at: and #at:put: using nativeboost. Implement various stuff to fully cover Collection protocol, implement any extra stuff like blob operations (multiplication, addition etc) if you want. And you don't have to compete with FFI, since you can implement all primitives in NativeBoost without using any external functions. You can use any kind of optimizations in native code, which are not available in C, like using SSE/SIMD instructions etc. Even more, you can detect a CPU type, and depending on that, generate a most efficient code for your little class/library. > > Do callbacks, and you gain a lot of ground. Â Make calls on separate threads, and you gain a LOT of ground. Â That assumes that you can make it simple enough for a mildly above-average C programmer to understand how to use and ideally extend it. Â I will look at your example package on Squeak Source. Callbacks is there. See NBFFICallbackTests>>benchQSort for example. > > One thing that drives me nuts with the Linux vm is that it looks for things where it wants to look, and gives no feedback about what it tried to do or even that it failed (except that handle is still zero). Â Your callout pragmas take a module name; is there any way to see inside of that or to provide a full path to the library? Â It is nice to be able to confirm loading of a library w/o having to call something, since there won't always be something "safe" (free of side effects) to call as a test. > Wait, there is no callout pragmas.. All stuff which starts from ^ NBFFICallout cdecl: #( double ( void * address) ) ... is smalltalk code, and you can debug it and see what it does, and how it loading a module and retrieving an external function pointer from it. You can customize this procedure in any way you want (by subclassing NBFFICallout), you can even customize the way how you making a call. For instance, in NBOpenGL, a generated code does not making a direct call to previously discovered function address. It using an sub-instance of NBOpenGLAPIBase, which is a variable-sized object, holding a function pointers, and it reads a corresponding pointer from this object, and only then making a call. So, there are plenty various tricks which can be done without much hassle. You just need to step away from rigid patterns, imposed by C compler, linker and all stuff around that, and you will see, that you can do miracles in smalltalk + native code :) > At the risk of seeming difficult, everything is academic until we have a Linux plugin or at least can build same. Â Alien has that problem. I'm working on that. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, September 22, 2010 10:05 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] NativeBoost examples (was: Re: Â DoubleArray) > > On 23 September 2010 02:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> Fair enough :) Â The most recent thing I recall on NativeBoost is Stef asking for what I assume must be a Mac plugin; I thought Linux would be left out too, but it appears not, though it is not in my current vm. Â Beyond some list traffic, I found this: >> > > The work for supporting Linux and Mac is in progress. > >> Â http://code.google.com/p/nativeboost/wiki/NativeBoost >> >> Is there other documentation somewhere? Â Build instructions? > > You can find all existing documentation, installation instructions on > wiki pages at the above site. There is no other place for it. > http://code.google.com/p/nativeboost/wiki/Installation - installation > instructions. > >> You have a block copy, which is good. Â What about indexing, such as getting floats or doubles out of external memory? > > This is just a piece of cake. Â ;) > > readDoubleFrom: address > Â Â Â Â " This method loads the double from given external address. > Â Â Â Â an address can be an instance of NBExternalAddress, or > Â Â Â Â simple ByteArray with at least 8 bytes long, which holds a double > floating value" > > Â Â Â Â <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > Â Â Â Â "We are using a pseudo-function prototype and supplying own assembler code, > Â Â Â Â instead of making a call to external function. > Â Â Â Â In given example, an address argument , after coercion is pushed on stack. " > > Â Â Â Â ^ NBFFICallout > > Â Â Â Â Â Â Â Â cdecl: #( double ( void * address) ) > Â Â Â Â Â Â Â Â " A pseudo-function takes 1 argument, and returns double value. > Â Â Â Â Â Â Â Â Â Under cdecl call convention, all floating point return types is > returned in fp(0) CPU register" > > Â Â Â Â Â Â Â Â emitCall: [:gen | Â | asm | > Â Â Â Â Â Â Â Â Â Â Â Â asm := gen asm. > > Â Â Â Â Â Â Â Â Â Â Â Â "Here , we expecting that an address value is already pushed on stack" > > Â Â Â Â Â Â Â Â Â Â Â Â asm pop: asm EAX; Â "load an address value into EAX register by > popping a stack" > Â Â Â Â Â Â Â Â Â Â Â Â fld: (asm EAX ptr64). "load a floating point value from memory, at > base address, held in EAX register into fp(0) register, > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â we are using #ptr64, to indicate that memory operand size is 64bits long" > > Â Â Â Â Â Â Â Â Â Â Â Â " return value set, we are done. A code generator will take care > for emitting code, which converts > Â Â Â Â Â Â Â Â Â Â Â Â a double floating point value into smalltalk object. " > Â Â Â Â Â Â Â Â ] > > I just uploaded this example and also how to write doubles from/to memory. > See at SqS/NativeBoost - NativeBoost-Examples package, class NBBasicExamples. > >> I am very comfortable adding functions to a library for integer and float/double calculations on "large" arrays and calling them via FFI; plugins are another story. Â Are there examples to follow? > > Tell me, what examples you would like to see. I will gladly provide them. > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Wednesday, September 22, 2010 6:20 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] DoubleArray >> >> On 23 September 2010 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Henry, >>> >>> I have been getting away with #doubleAt: and #doubleAt:put:, and otherwise doing pretty much what you said, though I just use a byte array to hold the data. Â It seems to work; for FFI, I end up passing void pointers instead of double pointers, which I don't like doing. >>> >>> Your point about using ordinary arrays makes sense to a point, though even w/o external interfacing, there is still a use for DoubleArray just as there is a use for String vs. an array of characters. >>> >> >> The main reason, why they are not here, that VM needs an additional >> set of primitives, which working with them. >> >> <sellsman hat on> >> I can only say that with NativeBoost, you could be able to implement >> it quite easily in image and ship it in image, >> without a need to change VM or use external plugin. >> <sellsman hat off> >> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] >>> Sent: Wednesday, September 22, 2010 5:23 PM >>> To: pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] DoubleArray >>> >>> Â On 22.09.2010 23:09, Schwab,Wilhelm K wrote: >>>> Squeak, deliberately, does not have a double array class. Â Is that because there is some horrible reason it can't work, or because it won't work on certain platforms? >>> If the goal is to pass it as a parameter to an external function, one >>> way would be to subclass WordArray, storing(and reading) each Float in >>> two elements, and have the endianness decided by Smalltalk endianness. >>> Probably want a startUp method for the class to swap instances >>> endianness if the platform has changed as well. >>>> Put another way, should we add such a class, if only via an external heap or whatever would be needed to make it reliable? >>>> >>>> Bill >>> More likely because no one has actually had a need for one. >>> It's definitely not _needed_ in base, where normal arrays of floats >>> would do the same job just as well, if not better. >>> IMHO, if someone makes one, it so should probably be part of a package >>> related to external interfacing. >>> >>> Cheers, >>> Henry >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2010

Re: [Pharo-project] HashedCollection showstopper :(

by Igor Stasenko

2010/9/23 Levente Uzonyi <leves(a)elte.hu>: > On Wed, 22 Sep 2010, Igor Stasenko wrote: > >> Unfortunately, when preparing new finalization stuff, i got stuck with >> HashedCollection >> which is not yet integrated to Pharo. >> (Sets with nils also depending on that). >> >> In Squeak, old WeakRegistry does the trick by setting a #finalizer: to >> WeakKeyDictionary instance. >> >> Levente, can i ask you to give me a bits, (changesets or mcz packages), >> which contain HashedCollection refactorings. > > I could extract them from the Squeak trunk, but it wouldn't be usable for > Pharo, because these rely on previous changes done to Sets/Dictionaries in > Squeak. Even if those are extracted it's still very hard to add them to > Pharo, because there were serveral changes applied to Sets/Dictionaries in > Pharo. The most important are: > - AndrÃ©s' changes were integrated with additional stuff to change > #identityHash -> #basicIdentityHash and #scaledIdentityHash -> > #identityHash. - WeakKeyDictionaries were replaced with another > implementation (http://code.google.com/p/pharo/issues/detail?id=1565 ) > > I think i found a way how to workaround differences between squeak/pharo in new WeakRegistry class. So, then a new finalization can be integrated into Pharo right now. Will post later, if i'll have any success on that. > Levente > >> >> Or, we can follow an easier path, just extract the delta from two >> packages, >> which i found in mail archives: >> --- >> I uploaded two packages which contain this change. To load it evaluate >> the following: >> >> (Installer squeakfoundation project: 'inbox') >> Â Â Â install: 'Collections-ul.310.mcz'; >> Â Â Â install: 'Collections-ul.311.mcz' >> --- >> >> these are only related to WeakKeyDictionary, made by Levente to >> speedup old finalization. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2010

Re: [Pharo-project] decompiledSource

by Henrik Johansen

On Sep 23, 2010, at 1:35 18PM, Herve Verjus wrote: > Hello All, > > I would like to port some VisualWorks code into Pharo. The VW current project code uses VW Kernel.decompiledSource that does not seem to be implemented in Pharo...Is there a Pharo method that does the same...Is there someone with an idea ? > > Thank you... > > Herve If you mean CompiledBlock/CompiledCode #decompiledSource, I think the equivalent in Pharo would be BlockClosure / CompiledMethod #decompile Cheers, Henry

Sept. 23, 2010

[Pharo-project] decompiledSource

by Herve Verjus

Hello All, I would like to port some VisualWorks code into Pharo. The VW current project code uses VW Kernel.decompiledSource that does not seem to be implemented in Pharo...Is there a Pharo method that does the same...Is there someone with an idea ? Thank you... Herve

Sept. 23, 2010