January 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Library to use multi-core in Pharo?

by Ben Coman

On Thu, 10 Jan 2019 at 00:19, Alexandre Bergel via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hi! > > Is there an effort to easily use multi-core or native processes in Pharo? > I am thinking about a library that offer a construct like: > > future := Runner runInDifferentProcess: [ âThis block is run in a > different OS processâ ] > > That would save the image under a different name, use OSSubProcess to > launch a new Pharo with no UI. > > Is there a library available? > maybe not the full answer you were hoping for, but just you a side thought... One thing I've been curious about for a while is how the system might behave if via FFI you call fork() or clone(), and use Kilon's CPP Bridge [1] for return values. [1] https://github.com/kilon/CPP cheers -ben

Jan. 10, 2019

Re: [Pharo-users] Library to use multi-core in Pharo?

by Pierce Ng

On Wed, Jan 09, 2019 at 01:18:45PM -0300, Alexandre Bergel via Pharo-users wrote: > Is there an effort to easily use multi-core or native processes in Pharo? > I am thinking about a library that offer a construct like: There used to be a Hydra VM for Squeak: http://squeakvm.org/~sig/hydravm/devnotes.html >From the developer notes: A HydraVM encapsulates full interpreter state in single object. This allowing it to support as many as needed interpreter instances to be run using different native threads. Most of VM functions (and all primitives) now require an additional argument - interpreter instance. Pierce

Jan. 10, 2019

[ANN] MaterialDesignLite v2.0.0

by Cyril Ferlicot D.

Hello, Today I released the version v2.0.0 of MaterialDesignLite for Seaside. (https://github.com/DuneSt/MaterialDesignLite/releases/tag/v2.0.0) This release does not brings much new features but it contains all breaking changes that accumulated in the issue tracker. (That's why it's a major release). The main changes are: - Migration to Tonel (People using Gemstone might need to stick to v1.x.x) - Removal of all deprecated classes and methods - I added named URLs in the demo to be able to send links of pages or example - Addition of a Pagination widget as extension of MDL (https://mdl.ferlicot.fr/mdl/Extensions/Pagination) A migration guide can be found here: https://github.com/DuneSt/MaterialDesignLite/blob/v2.0.0/resources/migratio… This release is tagged with v2.0.0 and I also introduced tags v2.x.x and v2.0.x which are moving tags following patch and minor versions. Here is the full changelog of the release: https://github.com/DuneSt/MaterialDesignLite/blob/v2.0.0/CHANGELOG.md If you have issues, need a new feature or have a comment on the project feel free to open a issue: https://github.com/DuneSt/MaterialDesignLite/issues I also updated the demo: https://mdl.ferlicot.fr/ Have a nice day! -- Cyril Ferlicot https://ferlicot.fr

Jan. 10, 2019

Re: [Pharo-users] NeoJSON Custom Mapping Question

by Eric Gade

Hi Sven, thanks for the response. Unfortunately since I'm working with a standard here, there is always going to be an explicit `"type": <foo>` attribute rather than having the key itself be the name of the type. I guess I'll stick to the two-pass read solution. But the writing solution can use the mapping so that saves a lot of trouble! On Wed, Jan 9, 2019 at 3:14 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Eric, > > > On 9 Jan 2019, at 00:34, Eric Gade <eric.gade(a)gmail.com> wrote: > > > > Hey guys, > > > > I'm toying with the idea of a Pharo implementation of ActivityStreams ( > https://www.w3.org/TR/activitystreams-core/#introduction) which is based > on a subset of JSON called JSON-LD (for "linked data"). > > > > While I do not believe this would entail creating a whole JSON-LD > implementation, I do have a question about how to implement > reading/writing/mapping to and from the core set of object types in the > specification. > > > > I am aware that giving any class #neoJsonMapping allows one to define > the specifics of the mapping to and from objects of that class (I think > this is super cool, by the way). The issue with ActivityStreams objects is > that the "type" of object they represent is in the JSON itself as the > property "type," for example: > > > > ``` > > { > > "@context": "https://www.w3.org/ns/activitystreams", > > "name": "A simple note", > > "type": "Note", > > "id": "http://www.test.example/notes/1", > > "content": "A simple note", > > "replies": { > > "type": "Collection", > > "totalItems": 1, > > "items": [ > > { > > "name": "A response to the note", > > "type": "Note", > > "content": "A response to the note", > > "inReplyTo": "http://www.test.example/notes/1" > > } > > ] > > } > > } > > ``` > > > > This refers to a top level ActivityStream object of type "Note" which we > maybe want to parse into something like `ASNote`. > > > > My core question is this: how can we get a NeoJSONReader to determine > which type of object to create by checking for a "type" property as soon as > possible in the process? Because this property can show up in any order, we > won't know what type of object to create until it is encountered. What is > the best strategy there? > > > > Does the complexity suggest that we should simply parse incoming > ActivityStream objects into the collection-and-dict default mapping and > deal with creating the appropriate objects after that? In this case we > could still use the custom mapping for the writing, which is not a problem > since the "type" field will be associated with the class (ie, ASNote class > >> #type will respond with 'Note' and we can go from there). > > > > Any thoughts or suggestions much appreciated! > > You describe the situation correctly: NeoJSON operates in 2 modes: > > (1) generating generic Arrays and Dictionaries (just like the spec) > > or > > (2) optionally mapping, stream based, directly, without intermediary > representation, into domain instances (given a predefined static mapping) > > Using NeoJSONObject instead of Dictionary is just a convenience (it being > a more JS like object). > > There is indeed another approach, using dynamic typing, that is not > specifically supported in NeoJSON. > > As you remark yourself, that requires an intermediary representation, so > one could just as well use option (1) and convert 'manually' in a second > pass. > > That being said, it could/would be a nice addition to offer some support > for this. Although there are multiple slightly different approaches. For > example, there also is > > { > "Point" : { "x" : 1, "y" : 2 } > } > > Instead of > > { > "_type" : "Point", > "x" : 1, > "y" : 2 > } > > The key for the type/class can be different, the value can be anything, > even 'com.java.graphics.Point'. > > Note also that typically, there are no collection types (and these would > be way more complicated). > > Sven > > > -- > > Eric > > > -- Eric

Jan. 9, 2019

Re: [Pharo-users] [ANN] P3 version 1.1

by Tudor Girba

Perfect. Then I will continue in our repo and we see later. Doru > On Jan 9, 2019, at 9:36 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 7 Jan 2019, at 20:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Excellent. >> >> In the meantime, we extended GT4P3 a bit to also navigate Schemas and Tables' structure. >> <gt4p3-schema-tables.png> >> >> For this, I introduced a few classes such as Database, Schema or Table to ease the inspection and tool creation. Itâs a bit naive for now, but it works quite well. Should these be committed to the P3 directly to enable an object-oriented API for drilling through the DB? > > Yes, that is what I meant. > I looked at your code (https://github.com/feenkcom/gt4p3) and I understand the reification. > But like you say, the usefulness of these objects beyond this exploration is questionable. > One of the goals of P3 is to be lean and mean, to not offer much framework in how you should make use of it, that should be done by another layer like Glorp. > We'll see how this evolve going forward. > >> Cheers, >> Doru >> >> >> >>> On Jan 6, 2019, at 9:17 PM, Sven Van Caekenberghe via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >>> >>> >>> From: Sven Van Caekenberghe <sven(a)stfx.eu> >>> Subject: Re: [Pharo-users] [ANN] P3 version 1.1 >>> Date: January 6, 2019 at 9:17:34 PM GMT+1 >>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>> >>> >>> Nice, I just added convenience methods #listDatabases #listSchemas and #listTablesInSchema: to P3Client so you should be able to make a real browser, connection >> schemas >> tables >> contents (listDatabases is not so useful since you can only connect to 1 database at a time). >>> >>>> On 6 Jan 2019, at 00:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> And with a little more code, we now have a dedicated Playground form snippet that opens the database connection without requiring any Pharo code. >>>> >>>> <gt4p3-snippet.png> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Jan 5, 2019, at 12:02 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> You can now query a Postgres database from the new GT. The initial code is available here: >>>>> https://github.com/feenkcom/gt4p3 >>>>> >>>>> It currently looks like this: >>>>> <gt-inspector-p3-query.png> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>>> On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I created a new release of P3, the modern, lean and mean PostgreSQL client for Pharo. >>>>>> >>>>>> https://github.com/svenvc/P3 >>>>>> >>>>>> Version 1.1 contains the following changes: >>>>>> >>>>>> - added support for Postgres Extended Query protocol (P3PreparedStatement) (thx Jan @jvdsandt) >>>>>> - added support for reading array type values (currently INTEGER[] FLOAT[] BOOLEAN[] TEXT[] VARCHAR[]) >>>>>> - added P3-Tests package and moved all tests there >>>>>> - more comments >>>>>> - more unit tests >>>>>> >>>>>> https://github.com/svenvc/P3/releases/tag/v1.1 >>>>>> >>>>>> >>>>>> Especially Jan's contribution adds a lot of functionality: the ability to work with prepared statements. >>>>>> >>>>>> Here is an example doing a batch insert of 100 records (which is more efficient). >>>>>> >>>>>> | client statement | >>>>>> >>>>>> client := P3Client url: 'psql://sven@localhost'. >>>>>> >>>>>> client execute: 'DROP TABLE IF EXISTS table1'. >>>>>> client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at TIMESTAMP DEFAULT NOW(), name TEXT)'. >>>>>> >>>>>> statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'. >>>>>> statement executeBatch: ((1 to: 100) collect: [ :index | Array with: ('Text #', index printString) ]). >>>>>> >>>>>> client query: 'SELECT * FROM table1'. >>>>>> client execute: 'DROP TABLE table1'. >>>>>> >>>>>> statement close. >>>>>> client close. >>>>>> >>>>>> >>>>>> Season's Greetings to you all. >>>>>> >>>>>> Sven >>>>>> >>>>>> >>>>>> -- >>>>>> Sven Van Caekenberghe >>>>>> Proudly supporting Pharo >>>>>> http://pharo.org >>>>>> http://association.pharo.org >>>>>> http://consortium.pharo.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> www.feenk.com >>>>> >>>>> "What is more important: To be happy, or to make happy?" >>>>> >>>> >>>> -- >>>> www.feenk.com >>>> >>>> "Quality cannot be an afterthought." >>>> >>> >>> >>> >>> >> >> -- >> www.feenk.com >> >> "No matter how many recipes we know, we still value a chef." > -- www.feenk.com âLive like you mean it."

Jan. 9, 2019

Re: [Pharo-users] Library to use multi-core in Pharo?

by Thierry Goubier

Oh well, sorry. I checked and ... it seemed taskit could do it, but now it seems to be a future extension. However OSProcess can do it: look at #forkSqueak. Thierry Le mer. 9 janv. 2019 Ã 21:36, Thierry Goubier <thierry.goubier(a)gmail.com> a Ã©crit : > > Hi Alexandre, > > look at taskit: (https://github.com/sbragagnolo/taskit) I think it > can do what you are looking for. I think that OSProcess is also able > to do that via fork calls. > > Having minimal, light weight images without complex loading > preferences and whatever would help, otherwise simply forking your > current image could be faster. > > Thierry > > Le mer. 9 janv. 2019 Ã 19:42, Alexandre Bergel via Pharo-users > <pharo-users(a)lists.pharo.org> a Ã©crit : > > > > Hi! > > > > Is there an effort to easily use multi-core or native processes in Pharo? > > I am thinking about a library that offer a construct like: > > > > future := Runner runInDifferentProcess: [ âThis block is run in a different OS processâ ] > > > > That would save the image under a different name, use OSSubProcess to launch a new Pharo with no UI. > > > > Is there a library available? > > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Jan. 9, 2019

Re: [Pharo-users] Library to use multi-core in Pharo?

by Thierry Goubier

Hi Alexandre, look at taskit: (https://github.com/sbragagnolo/taskit) I think it can do what you are looking for. I think that OSProcess is also able to do that via fork calls. Having minimal, light weight images without complex loading preferences and whatever would help, otherwise simply forking your current image could be faster. Thierry Le mer. 9 janv. 2019 Ã 19:42, Alexandre Bergel via Pharo-users <pharo-users(a)lists.pharo.org> a Ã©crit : > > Hi! > > Is there an effort to easily use multi-core or native processes in Pharo? > I am thinking about a library that offer a construct like: > > future := Runner runInDifferentProcess: [ âThis block is run in a different OS processâ ] > > That would save the image under a different name, use OSSubProcess to launch a new Pharo with no UI. > > Is there a library available? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

Jan. 9, 2019

Re: [Pharo-users] [ANN] P3 version 1.1

by Sven Van Caekenberghe

> On 7 Jan 2019, at 20:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Excellent. > > In the meantime, we extended GT4P3 a bit to also navigate Schemas and Tables' structure. > <gt4p3-schema-tables.png> > > For this, I introduced a few classes such as Database, Schema or Table to ease the inspection and tool creation. Itâs a bit naive for now, but it works quite well. Should these be committed to the P3 directly to enable an object-oriented API for drilling through the DB? Yes, that is what I meant. I looked at your code (https://github.com/feenkcom/gt4p3) and I understand the reification. But like you say, the usefulness of these objects beyond this exploration is questionable. One of the goals of P3 is to be lean and mean, to not offer much framework in how you should make use of it, that should be done by another layer like Glorp. We'll see how this evolve going forward. > Cheers, > Doru > > > >> On Jan 6, 2019, at 9:17 PM, Sven Van Caekenberghe via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >> >> >> From: Sven Van Caekenberghe <sven(a)stfx.eu> >> Subject: Re: [Pharo-users] [ANN] P3 version 1.1 >> Date: January 6, 2019 at 9:17:34 PM GMT+1 >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> >> >> Nice, I just added convenience methods #listDatabases #listSchemas and #listTablesInSchema: to P3Client so you should be able to make a real browser, connection >> schemas >> tables >> contents (listDatabases is not so useful since you can only connect to 1 database at a time). >> >>> On 6 Jan 2019, at 00:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> And with a little more code, we now have a dedicated Playground form snippet that opens the database connection without requiring any Pharo code. >>> >>> <gt4p3-snippet.png> >>> >>> Cheers, >>> Doru >>> >>> >>>> On Jan 5, 2019, at 12:02 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> You can now query a Postgres database from the new GT. The initial code is available here: >>>> https://github.com/feenkcom/gt4p3 >>>> >>>> It currently looks like this: >>>> <gt-inspector-p3-query.png> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>>> On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I created a new release of P3, the modern, lean and mean PostgreSQL client for Pharo. >>>>> >>>>> https://github.com/svenvc/P3 >>>>> >>>>> Version 1.1 contains the following changes: >>>>> >>>>> - added support for Postgres Extended Query protocol (P3PreparedStatement) (thx Jan @jvdsandt) >>>>> - added support for reading array type values (currently INTEGER[] FLOAT[] BOOLEAN[] TEXT[] VARCHAR[]) >>>>> - added P3-Tests package and moved all tests there >>>>> - more comments >>>>> - more unit tests >>>>> >>>>> https://github.com/svenvc/P3/releases/tag/v1.1 >>>>> >>>>> >>>>> Especially Jan's contribution adds a lot of functionality: the ability to work with prepared statements. >>>>> >>>>> Here is an example doing a batch insert of 100 records (which is more efficient). >>>>> >>>>> | client statement | >>>>> >>>>> client := P3Client url: 'psql://sven@localhost'. >>>>> >>>>> client execute: 'DROP TABLE IF EXISTS table1'. >>>>> client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at TIMESTAMP DEFAULT NOW(), name TEXT)'. >>>>> >>>>> statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'. >>>>> statement executeBatch: ((1 to: 100) collect: [ :index | Array with: ('Text #', index printString) ]). >>>>> >>>>> client query: 'SELECT * FROM table1'. >>>>> client execute: 'DROP TABLE table1'. >>>>> >>>>> statement close. >>>>> client close. >>>>> >>>>> >>>>> Season's Greetings to you all. >>>>> >>>>> Sven >>>>> >>>>> >>>>> -- >>>>> Sven Van Caekenberghe >>>>> Proudly supporting Pharo >>>>> http://pharo.org >>>>> http://association.pharo.org >>>>> http://consortium.pharo.org >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> www.feenk.com >>>> >>>> "What is more important: To be happy, or to make happy?" >>>> >>> >>> -- >>> www.feenk.com >>> >>> "Quality cannot be an afterthought." >>> >> >> >> >> > > -- > www.feenk.com > > "No matter how many recipes we know, we still value a chef."

Jan. 9, 2019

Re: [Pharo-users] Documentation on Traits

by Torsten Bergmann

Maybe this collection in my wiki can help you:Â http://wiki.astares.com/pharo/115 There are also many tests in the image that you can check regarding traits, slots, meta links, ... so you have the source luke. Bye T.Â Â

Jan. 9, 2019

Re: [Pharo-users] Library to use multi-core in Pharo?

by HernÃ¡n Morales Durand

Hi Alex, I think you could launch jobs using GNU parallel, otherwise for shared memory parallelism OpenMP is a common choice. There is an old thread: http://forum.world.st/NativeBoost-and-OpenMP-td4837865.html but no library AFAIK Cheers, HernÃ¡n El miÃ©., 9 ene. 2019 a las 16:56, Alexandre Bergel via Pharo-users (< pharo-users(a)lists.pharo.org>) escribiÃ³: > Hi! > > Is there an effort to easily use multi-core or native processes in Pharo? > I am thinking about a library that offer a construct like: > > future := Runner runInDifferentProcess: [ âThis block is run in a > different OS processâ ] > > That would save the image under a different name, use OSSubProcess to > launch a new Pharo with no UI. > > Is there a library available? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Jan. 9, 2019