August 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Your success stories ...

by Johan Fabry

Hi, I just looked at this page (Firefox 31, Mac OSX 10.9.3) and the images are zoomed like 500%, they are huge. I think this is not the intent, it would be good if this is looked at. Greetings, On Jul 31, 2014, at 2:12 AM, stepharo <stepharo(a)free.fr> wrote: > "Pharo success stories" is getting started at > > http://www.pharo.org/success > > TrentoSur http://trentosur.com looks so sexy > > Please send me information about yours they will be added to the pending queue > > Stef > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Aug. 5, 2014

Re: [Pharo-users] NativeBoost: use of array

by Thomas Bany

All right ! Tanks again for you answers and kudos for the NB plugin ! I was kinda scared of doing stuff outside of the image but everything went super smooth. 2014-08-05 16:45 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > > > On 4 August 2014 16:45, Thomas Bany <mun.sysdev(a)gmail.com> wrote: > >> Hi again ! >> >> >> I'm having trouble to call the function with the following prototype : >> >> void propagateTLE(orbit_t orb, double secondSince[], xyz_t * out, size_t >>> nbEpoch) >> >> >> with the corresponding NB call: >> >> self nbCall: #( void propagateTLE(orbit_t orbit, double * secondSince, >>> xyz_t * out, size_t nbEpoch) ) >> >> >> The argument *secondSince* is an input and the argument *out* is the >> output pointer that the function should fill. I have made 2 subclass of >> NBExternalArray to feed this function, (allmost) namely: *ArrayOfDoubles >> *and *ArrayOfXYZ*. Should I mention that type *xyz_t* is a struct that I >> modeled with an *NBExternalStructure*. >> >> I face 2 issues: >> >> - The type *ArrayOfXYZ* is refused as an *xyz_t** type. However, the *ArrayOfDoubles >> *is accepted as a *double** type. >> - If a get rid of the *out* argument to test the array *secondSince*, >> I get an undefined error (Error durring FFI call: nil). >> >> >> >> My current solution is to use the adress of my arrays and the following >> NB call: >> >> self nbCall: #( void propagateTLE(orbit_t orbit, NBExternalAddress >>> secondSince, NBExternalAddress out, size_t nbEpoch) ) >> >> >> if you explicitly specify NBExternalAddress, then it won't accept any > other argument than instance of NBExternalAddress. > > Also, note there's no marshallers for (sub)instances of NBExternalArray, > and thus you cannot pass them directly, but only by passing pointer to its > elements using #address method. > > I.e, if you using 'whatever *', you can pass a pointer to array by: > myArray address. > > > >> But it feels like I'm cheating my way trough, by pretty much avoiding any >> type check. Any clue as to why the typecheck of NB is refusing to call my >> function ? >> >> >> Thanks in advance, >> >> Thomas. >> >> > > > -- > Best regards, > Igor Stasenko. >

Aug. 5, 2014

Re: [Pharo-users] NativeBoost: use of array

by Igor Stasenko

On 4 August 2014 16:45, Thomas Bany <mun.sysdev(a)gmail.com> wrote: > Hi again ! > > > I'm having trouble to call the function with the following prototype : > > void propagateTLE(orbit_t orb, double secondSince[], xyz_t * out, size_t >> nbEpoch) > > > with the corresponding NB call: > > self nbCall: #( void propagateTLE(orbit_t orbit, double * secondSince, >> xyz_t * out, size_t nbEpoch) ) > > > The argument *secondSince* is an input and the argument *out* is the > output pointer that the function should fill. I have made 2 subclass of > NBExternalArray to feed this function, (allmost) namely: *ArrayOfDoubles *and > *ArrayOfXYZ*. Should I mention that type *xyz_t* is a struct that I > modeled with an *NBExternalStructure*. > > I face 2 issues: > > - The type *ArrayOfXYZ* is refused as an *xyz_t** type. However, the *ArrayOfDoubles > *is accepted as a *double** type. > - If a get rid of the *out* argument to test the array *secondSince*, > I get an undefined error (Error durring FFI call: nil). > > > > My current solution is to use the adress of my arrays and the following NB > call: > > self nbCall: #( void propagateTLE(orbit_t orbit, NBExternalAddress >> secondSince, NBExternalAddress out, size_t nbEpoch) ) > > > if you explicitly specify NBExternalAddress, then it won't accept any other argument than instance of NBExternalAddress. Also, note there's no marshallers for (sub)instances of NBExternalArray, and thus you cannot pass them directly, but only by passing pointer to its elements using #address method. I.e, if you using 'whatever *', you can pass a pointer to array by: myArray address. > But it feels like I'm cheating my way trough, by pretty much avoiding any > type check. Any clue as to why the typecheck of NB is refusing to call my > function ? > > > Thanks in advance, > > Thomas. > > -- Best regards, Igor Stasenko.

Aug. 5, 2014

Re: [Pharo-users] Finalization question

by Udo Schneider

On 05.08.2014 14:08, Udo Schneider wrote: > I also reduced the testcases to even show a (IMHO) faulty behavior w/o > any process at all. Simple references are sufficient. I just created a small TestCase showing the (IHMO) faulty behavior. I hope the intention is clear from the package/var names. Gofer it smalltalkhubUser: 'UdoSchneider' project: 'Playground'; package: 'CyclicFinalizationBug'; load. Check out the tests in CyclicFinalizationBugTestCase. Hope this helps. CU, Udo

Aug. 5, 2014

Re: [Pharo-users] NativeBoost: use of array

by Pierce Ng

On Mon, Aug 04, 2014 at 04:45:46PM +0200, Thomas Bany wrote: > self nbCall: #( void propagateTLE(orbit_t orbit, NBExternalAddress > > secondSince, NBExternalAddress out, size_t nbEpoch) ) > > But it feels like I'm cheating my way trough, by pretty much avoiding any > type check. Any clue as to why the typecheck of NB is refusing to call my > function ? I'm not sure if this addresses (heh) your issue, but in NBSQLite3, I do what Punqlite does: NBSQLite3FFI class>>initializeTypeMap TypeMap := Dictionary newFromPairs: #( sqlite3 NBExternalObject sqlite3_stmt NBExternalObject sqlite_int64 NBInt64 ) NBSQLite3FFI class>>nbBindingOf: aTypeName ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName ] NBSQLite3FFI>>apiOpen: filename via: handle "int sqlite3_open(const char*, sqlite3**)" <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCall: #(int sqlite3_open (String filename, sqlite3* handle)) module: self library "handle" is the out parameter in sqlite3_open(). NBSQLite3 is at http://ss3.gemtalksystems.com/ss/NBSQLite3. Punqlite is on Smalltalk Hub. -- Pierce Ng http://www.samadhiweb.com/blog/

Aug. 5, 2014

Re: [Pharo-users] Finalization question

by Udo Schneider

On 05.08.2014 12:10, Santiago Bragagnolo wrote:> TaskIT has a feature named StickyReference, for that propouse, is not > trivial at all, because when you fork you are using a block that has a > reference to a context. In the end even if your variable is nil, your > process is being pointed by the context. You're feeding my deepest fears :-) I also reduced the testcases to even show a (IMHO) faulty behavior w/o any process at all. Simple references are sufficient. Still I'm wondering what's the official way to solve that problem. IMHO objects with forked background processes which want to terminate those processes implicitly using finalization isn't something uncommon ... CU, Udo

Aug. 5, 2014

Re: [Pharo-users] Finalization question

by Santiago Bragagnolo

TaskIT has a feature named StickyReference, for that propouse, is not trivial at all, because when you fork you are using a block that has a reference to a context. In the end even if your variable is nil, your process is being pointed by the context. What i did in TaskIT is to have a witness object, that mixed with a ghost proxy (the one you will be pointing) can do the magic. If what you want in your process variable is not really a reference to the process or if you have enough with a partial proxy based in DNU, things can go easier, you just need to register that third object into the weak resgistry. If you check out taskit commit 20 you will find a mechanism based in a DNU based proxy. If you checkout the last stable version you will find the witness/ghost proxy based one. In any case, look for the method asStickyReference. It will lead you straight to the mechanism. Gofer new smalltalkhubUser: 'CAR' project: 'TaskIT'; configuration; load. (#ConfigurationOfTaskIT asClass project version: #stable) load: 'full' 2014-08-05 11:22 GMT+02:00 Udo Schneider <Udo.Schneider(a)homeaddress.de>: > On 04.08.2014 21:35, stepharo wrote:> We should write a chapter on > finalization but since I do not know it > > > well (and I forget)... > > igor will answer you. > > > > Stef > > I found "the" bug. It seems it's a side effect of finalization, > WeakRegistry and cyclic references. I'll write a TestCase for that. > > Thanks, > > Udo > > > > >

Aug. 5, 2014

Re: [Pharo-users] Finalization question

by Udo Schneider

On 04.08.2014 21:35, stepharo wrote:> We should write a chapter on finalization but since I do not know it > well (and I forget)... > igor will answer you. > > Stef I found "the" bug. It seems it's a side effect of finalization, WeakRegistry and cyclic references. I'll write a TestCase for that. Thanks, Udo

Aug. 5, 2014

Re: [Pharo-users] [Moose-dev] Re: Tree/Outliners of playgrounds, markdown inside comments and some quick medium size dreams for Pharo/Smalltalk

by Tudor Girba

Hi, You probably need this: explorer transmit to: #tree; andShow: [:a | a tree display: headers; *children: [:eachNode | eachNode theMessageYouUseToGoToTheChildrenOfANode ]*]. A tree is a recursive structure, and to describe it you need: - a way to construct the root elements. This is the result of applying display: to the input object. So, display: either takes a collection or a block that will return a collection when executed. - a way to define the children for each node. This is the result of applying children: You should also take a look at the examples from: GLMBasicExamples open Does this help now? Cheers, Doru On Sun, Jul 27, 2014 at 4:59 PM, Offray Vladimir Luna CÃ¡rdenas < offray(a)riseup.net> wrote: > Hi, > > Answering to myself: I have solved the code that selects the headers of > the main tree. The key is to create a new collection containing only node > names. Here is the code: > > "*************************" > | mainTree node1 node2 explorer headers | > > mainTree := UbakyeNode > header: 'Arbol raÃz' > body: ''. > > node1 := UbakyeNode > header: 'Nodo 1' > body: 'Texto 1'. > > node2 := UbakyeNode > header: 'Nodo 2' > body: 'Texto 2'. > > mainTree > addNode: node1; > addNode: node2. > > > explorer := GLMTabulator new > title: (mainTree header). > explorer column: #tree; > column: #body. > > headers := (mainTree children) > collect: [:node | node header]. > > > explorer transmit to: #tree; andShow: [:a | > a tree > display: headers]. > > explorer openOn: mainTree. > > "*************************" > > Now I need to make the children sellectable, and that all the contents of > the tree can be updated with a shortcut. > > I will keep you posted. > > Cheers, > > Offray > > > On 07/26/2014 09:01 PM, Offray Vladimir Luna CÃ¡rdenas wrote: > >> Hi again, >> >> I will be using this thread to update my advances and questions about >> how to build an outliner in Pharo Smalltalk. If there is a better method >> like starting a new thread for particular questions, or a less narrative >> style, please let me know. >> >> The idea is to use the tools provided by Moose to build a quick outliner >> that can be extended to suit my needs on academical writing. This is >> kind of a strange approach in the sense that I'm not following the >> tutorials with a predefined problems (make a game and so) but trying to >> start with a real (in the sense of closer) problem (making an outliner) >> and to see which knowledge I need to solve this necessity. In that sense >> is more like the Freire's alphabetization of adults in Brazil. >> >> So, the things I have done so far was to search for a good model to >> start with. Something already done that can be used as scaffolding for >> my outliner. The Help System seems like a good start for an outliner (in >> fact it is already one), so I have taken the Help-Core system and start >> to use it as a base for my project. >> >> After that I have used the Moose browsers to build a simple interface, >> as seen here: >> >> http://mutabit.com/offray/static/blog/output/galleries/ >> objetos/ubakye-browser.jpg >> >> >> The part I want to deal with is this: >> >> =============== >> >> explorer := GLMTabulator new >> title: (mainTree header). >> explorer column: #tree; >> column: #body. >> >> explorer transmit to: #tree; andShow: [:a | >> a tree >> display: mainTree children ]. >> >> explorer openOn: mainTree. >> >> =============== >> >> So, instead of "display: mainTree children" I need something that takes >> the get names (headers) of the two nodes and the contents in the right >> panel. For that I think that I need to learn some iterators. I have >> already a "header" method for the nodes. Any clue would be appreciated >> and I will keep you posted on my advances. >> >> Cheers, >> >> Offray >> >> >> On 07/21/2014 12:58 PM, Offray Vladimir Luna CÃ¡rdenas wrote: >> >>> Hi Damien, >>> >>> Thanks for your answer. Comments below. >>> >>> On 07/21/2014 11:09 AM, Damien Cassou wrote: >>> >>>> On Sat, Jul 19, 2014 at 2:47 AM, Offray Vladimir Luna CÃ¡rdenas >>>> <offray(a)riseup.net> wrote: >>>> >>>>> The first idea that comes to mind is using STON for storage nodes and >>>>> tree >>>>> information, so I can interchange it with the flatland files world >>>>> and keep >>>>> it readable. Sounds that reasonable? >>>>> >>>> >>>> >>>> without more information, it is hard to stay. Try with STON and change >>>> if that does not work :-). We have XML and JSON generators as well. >>>> >>>> >>> >>> This is a kind of raw preview of I'm talking about: >>> >>> http://www.enlightenment.org/ss/e-53cd4f36f021e9.68569046.jpg >>> >>> Of course in this case, it is just a Help browser with a Playground >>> window over it, but I would like to have something like Playgrounds >>> inside the help browser. I was trying to build a custom browser with >>> Glamour, but seems that Help Browser already has the machinery I'm >>> looking for. >>> >>> So my first question is how to use the Help Browser class as a template >>> for my outliner class? And can I put a Playground where the plain text >>> is located right now? >>> >>> >>>> The second thing I would like to do is to add pandoc's markdown inside >>>>> comments, but I don't like the syntax of comments in Smalltalk because >>>>> single quotes are fairly easy to find in light markup language like >>>>> markdown. Is difficult to change it to create something more like >>>>> python >>>>> (with """) or Lua (with -[]- )? >>>>> >>>> >>>> >>>> There is only one syntax for comments in Pharo. Instead of Markdown, >>>> you might want to have a look at Pillar which is implemented in Pharo >>>> and can generate Markdown (and html, and pdf) : >>>> https://github.com/pillar-markup/pillar-documentation/ >>>> >>>> >>>> >>> I have seen Pillar. Seems really interesting, but Pandocs markdown >>> support academic citation in several formats and I have already long >>> docs wrote on that format integrated in my workflow from Zotero and even >>> there is a growing community working on Scholarly Markdown[1][2] so I >>> would like to stick with it as much as I can for my own writing. >>> That being said. I would like also a better integration between >>> Smalltalk outliners and all the academic publication work flow, >>> including working better with pandoc as a external library. >>> >>> [1] https://github.com/scholmd/scholmd/wiki >>> [2] >>> http://blog.martinfenner.org/2013/06/29/metadata-in-scholarly-markdown/ >>> [3] >>> http://programminghistorian.org/lessons/sustainable- >>> authorship-in-plain-text-using-pandoc-and-markdown >>> >>> >>> >>> Thanks again, this conversation with people in the community is very >>> valuable to me, >>> >>> Offray >>> >>> >>> >> >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 5, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Tudor Girba

Hi, Sorry I could not reply earlier. I will search the other mails where you ask the question and address it. Cheers, Doru On Mon, Aug 4, 2014 at 11:59 PM, Offray Vladimir Luna CÃ¡rdenas < offray(a)riseup.net> wrote: > I would like to help with the playground too. In several threads I have > argued about a tree/outliner like interface for organizing playgrounds and > making exploratory computation and visual data narratives. In fact I have > trying to understand how to build my own outliner from Moosee browsers, but > I have hit a wall about the use of "display: children:" syntax for trees, > but still no answer. Anyway playgrounds are a big improvement on user > experience and I hope to help with them. > > Cheers, > > Offray > > > On 06/04/2014 10:48 PM, S Krish wrote: > >> +100 >> I love this playground. Will explore it sometime.. and see if I can >> participate >> first in building tools for use and then dive into its frameworks ..! >> To get started I will need to have a minimum of Oracle connection rather >> than >> PostGres .. to make it worthwhile as I play with it. Any heads up on that >> is nice.. >> >> >> On Tue, Jun 3, 2014 at 12:45 PM, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >> The work on GToolkit goes in this direction. Funny enough, we also >> have a >> Playground :). >> >> Look here for an example: >> http://www.humane-assessment.com/blog/dynamic-exploration- >> of-a-postgres-db-with-the-gtinspector/ >> >> More will come in this direction. I happen to believe that this is >> the area >> with the largest potential in Pharo, and it would be great to put >> more >> effort around it. If people have an interest to participate, please >> just let >> me know. >> >> Cheers, >> Doru >> >> >> >> On Tue, Jun 3, 2014 at 9:02 AM, darrinm <darrin(a)massena.com >> <mailto:darrin@massena.com>> wrote: >> >> Here's an example of the Playground in use: >> https://developer.apple.com/library/prerelease/ios/ >> recipes/xcode_help-source_editor/ExploringandEvaluatingSwiftCod >> einaPlayground/ExploringandEvaluatingSwiftCodeinaPlayground.html#//apple_ >> ref/doc/uid/TP40009975-CH26 >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Xcode-s-Swift-Playground- >> tp4761425p4761431.html >> Sent from the Pharo Smalltalk Users mailing list archive at >> Nabble.com. >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> >> "Every thing has its own flow" >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 5, 2014