April 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Conditional external dependencies in a Metacello BaselineOf?

by Dale Henrichs

Damien, Peter's got the proper script ... When you lock a Metacello project, you are registering a repository with a project name, so no need to "load Baseline", the name and local repository are enogh to the job ... then do you normal load ... you do have to use the `Metacello new` form of project loading for the lock to take effect: Metacello new baseline: '...'; repository: '...'; onWarningLog; load Peter's script is a good example ... Dale On 4/13/16 1:40 AM, Peter UhnÃ¡k wrote: > Yes, I've been using this approach for some time. > > https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/dynacase… > > > > On Wed, Apr 13, 2016 at 2:24 AM, Damien Pollet > <damien.pollet+pharo(a)gmail.com <mailto:damien.pollet+pharo@gmail.com>> > wrote: > > Oh, nice! > > Just to be sure, because 2:15am is not the best time to start > playing with codeâ¦ if I understood correctly, I'd load the > depended-upon baseline from gitfiletree, lock it, and then that > would take precedence over the github:// repo specified in the > baseline of the main project? > > I'll try tomorrow, thanks :) > > On 13 April 2016 at 00:38, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > Damien, > > You want to use a a lock[1]. Look at the section on locking a > `filetree://` repo [2]--- should be similar for locking your > gitfiletree repo ... > > When you load you may want to use `onWarningLog`, because > locks do generate Warnings telling you the the lock is being > honored (i.e., the load is taking place from the local clone, > not github as specified in the baseline) ... > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… > [2] > https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… > > > > On 04/12/2016 11:18 AM, Damien Pollet wrote: > > I have a couple projects that I develop together; the > first depending on the second, and both managed on GitHub > (in separate repositories). > > The BaselineOf therefore expresses the dependency using > repository: 'github://â¦' > However, I'd like to locally change that to gitfiletree:// > so that I can build new development images from scratch, > with both projects ready to commit to gitfiletree, with > minimal repo juggling and code reloading ? > > Is there a way to achieve that? Metacello project > attributes? a git submodule? > > -- > Damien Pollet > type less, do more [ | ] > http://people.untyped.org/damien.pollet > > > > >

April 13, 2016

Re: [Pharo-users] FFI return by reference

by Esteban Lorenzano

Hi, Just checkedâ¦ contrary to what I believed, strings are passed by copy (not by reference, as ByteArray)â¦ logical for safety but with penalty on performance... so yes, using a ByteArray is the correct way to do it. (Or an external value holder, which is a glorified way for passing a ByteArray, but this probably do not work fine for âchar*" because I didnât preview it :P) Esteban > On 13 Apr 2016, at 05:24, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-04-11 15:10 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > > > On 11 Apr 2016, at 06:24, Thibault Raffaillac <thibault.raffaillac(a)inria.fr <mailto:thibault.raffaillac@inria.fr>> wrote: > > > >>> 1) Declare a class variable > >>> > >>> MyClass class>>initialize > >>> INT_PTR := FFIExternalValueHolder ofType: ?int?. > >> > >> as a larger explanation, this will create an anonymous subclass to keep ?int? > >> values, than later you can use as a type in your function call. Some people > >> would call this obscure, but is a good way of solving this problem (I > >> adopted it from old NB). > >> If you want to have a named class instead an anonymous class, you can just > >> subclass FFIExternalValueHolder: > >> > >> FFIExternalValueHolder subclass: #MyIntPtr > >> > >> and then implement typeDecl class method > >> > >> MyIntPtr class>>typeDecl > >> ^ ?int' > >> > >> and this will work as the anonymous class > > > > The second option is definitely what I want. > > Personally my option would be to put my types in a class pool and use them, not to extendâ¦ > but option is there so you can choose what you want :) > > > I am trying to expose a function returning several ints, as in SDL2>>mouseStateX: y: (excluding the possibility to return a Point). > > However I would rather not define my own int holder, can't we have generic holders to rely on? > > I will not add for the moment that predefined types value holdersâ¦ We would need to add one for each type we support to be consistent, and document it, and add tests. > And btwâ¦ you do have a generic holderâ¦ is just that you need to refine it to what you want :) > You could always use a ByteArray and took values later (some functions in Athens do it like that). The advantage of this approach (using plain ByteArrays) is that you do not need to change function signature at the cost of needing to do manually what the value holder does for you. > > Hi Esteban, > > is this the way it should be done for Strings ? > For example, old NBOpenGL had this Windows method to get the Window Title: > > getWindowText: hWnd buffer: lpString bufferSize: nMaxCount > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^self nbCall: #(int GetWindowTextA(HWND hWnd, char* lpString, int nMaxCount)) > module: #user32 > > called as: > > getWindowText > | len str | > str := ByteString new: 1000. > len := self getWindowText: self buffer: str bufferSize: 1000. > ^ str first: len. > > > When I just modify the ffiCall to > > getWindowText: hWnd buffer: lpString bufferSize: nMaxCount > > ^self ffiCall: #(int GetWindowTextA(HWND hWnd, char* lpString, int nMaxCount)) module: #user32 > > I get just an empty String. > > But If I call it with: > > | len str | > str := ByteArray new: 1000. > len := self getWindowText: self buffer: str bufferSize: 1000. > ^ String fromByteArray: (str first: len). > > I get the real string text. Is this the way to go? > > > > > My advise is that you go with what you need, we can consider add predefined value holders later. > > Esteban > > > > > Thibault > >

April 13, 2016

Re: [Pharo-users] Dawn Theme on Pharo 4.0

by Esteban Lorenzano

side note: I would like to have for themes and text-styling something similar to what I did for icons (external repository + a way to install them from image), but I donât have any time to do itâ¦ maybe a students project? (should be doable and fun, I think). side side note: I need also to refactor UITheme class to restore settings for theme colors (so everybody can customise their own) side note3: UITheme is not the way I would like to design a theme framework, but splitting everything "gtools style" does not looks fine either (hard to add new themes)â¦ anyway, this is not for now :) > On 13 Apr 2016, at 06:24, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > > > On Tue, Apr 12, 2016 at 8:54 PM, stepharo [via Smalltalk] <[hidden email] <x-msg://28/user/SendEmail.jtp?type=node&node=4889688&i=0>> wrote: > Super! > Could you publish it somewhere because for my vision I cannot use the dark theme. > > > Sure - I'll do that. I'm new to Pharo and have to look a bit into how, but I can make a fork on github and update the installation instructions or publish a package for pharo4 on Smalltalkhub. Do you prefer either site? > > -- Siemen > > > I cannot see what is written in red :). > > Stef > > Le 12/4/16 20:47, Siemen Baader a Ã©crit : >> On Tue, Apr 12, 2016 at 7:43 PM, stepharo <[hidden email] <http://user/SendEmail.jtp?type=node&node=4889618&i=0>> wrote: >> Check the code because it should just be a subclass of the dark theme >> with different colors. >> >> Stef >> >> Thanks, that helped me to adapt the instructions and make it work! >> >> -- Siemen >> > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Dawn-Theme-on-Pharo-4-0-tp4889541p4889618.html <http://forum.world.st/Dawn-Theme-on-Pharo-4-0-tp4889541p4889618.html> > To unsubscribe from Dawn Theme on Pharo 4.0, click here <applewebdata://D3FE6115-4E84-4774-AD47-F850F40EBB19>. > NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > > View this message in context: Re: Dawn Theme on Pharo 4.0 <http://forum.world.st/Dawn-Theme-on-Pharo-4-0-tp4889541p4889688.html> > Sent from the Pharo Smalltalk Users mailing list archive <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com.

April 13, 2016

Re: [Pharo-users] Dawn Theme on Pharo 4.0

by Siemen Baader

On Tue, Apr 12, 2016 at 8:54 PM, stepharo [via Smalltalk] < ml-node+s1294792n4889618h28(a)n4.nabble.com> wrote: > Super! > Could you publish it somewhere because for my vision I cannot use the dark > theme. > Sure - I'll do that. I'm new to Pharo and have to look a bit into how, but I can make a fork on github and update the installation instructions or publish a package for pharo4 on Smalltalkhub. Do you prefer either site? -- Siemen > I cannot see what is written in red :). > > Stef > > Le 12/4/16 20:47, Siemen Baader a Ã©crit : > > On Tue, Apr 12, 2016 at 7:43 PM, stepharo <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4889618&i=0>> wrote: > >> Check the code because it should just be a subclass of the dark theme >> with different colors. >> >> Stef >> > > Thanks, that helped me to adapt the instructions and make it work! > > -- Siemen > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Dawn-Theme-on-Pharo-4-0-tp4889541p4889618.html > To unsubscribe from Dawn Theme on Pharo 4.0, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Dawn-Theme-on-Pharo-4-0-tp4889541p4889688.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 13, 2016

Re: [Pharo-users] Conditional external dependencies in a Metacello BaselineOf?

by Peter UhnÃ¡k

Yes, I've been using this approach for some time. https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/dynacase… On Wed, Apr 13, 2016 at 2:24 AM, Damien Pollet < damien.pollet+pharo(a)gmail.com> wrote: > Oh, nice! > > Just to be sure, because 2:15am is not the best time to start playing with > codeâ¦ if I understood correctly, I'd load the depended-upon baseline from > gitfiletree, lock it, and then that would take precedence over the > github:// repo specified in the baseline of the main project? > > I'll try tomorrow, thanks :) > > On 13 April 2016 at 00:38, Dale Henrichs <dale.henrichs(a)gemtalksystems.com > > wrote: > >> Damien, >> >> You want to use a a lock[1]. Look at the section on locking a >> `filetree://` repo [2]--- should be similar for locking your gitfiletree >> repo ... >> >> When you load you may want to use `onWarningLog`, because locks do >> generate Warnings telling you the the lock is being honored (i.e., the load >> is taking place from the local clone, not github as specified in the >> baseline) ... >> >> Dale >> >> [1] >> https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… >> [2] >> https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… >> >> >> On 04/12/2016 11:18 AM, Damien Pollet wrote: >> >>> I have a couple projects that I develop together; the first depending on >>> the second, and both managed on GitHub (in separate repositories). >>> >>> The BaselineOf therefore expresses the dependency using repository: >>> 'github://â¦' >>> However, I'd like to locally change that to gitfiletree:// so that I can >>> build new development images from scratch, with both projects ready to >>> commit to gitfiletree, with minimal repo juggling and code reloading ? >>> >>> Is there a way to achieve that? Metacello project attributes? a git >>> submodule? >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >> >> >> >

April 13, 2016

Re: [Pharo-users] FFI return by reference

by Nicolai Hess

2016-04-11 15:10 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 11 Apr 2016, at 06:24, Thibault Raffaillac < > thibault.raffaillac(a)inria.fr> wrote: > > > >>> 1) Declare a class variable > >>> > >>> MyClass class>>initialize > >>> INT_PTR := FFIExternalValueHolder ofType: ?int?. > >> > >> as a larger explanation, this will create an anonymous subclass to keep > ?int? > >> values, than later you can use as a type in your function call. Some > people > >> would call this obscure, but is a good way of solving this problem (I > >> adopted it from old NB). > >> If you want to have a named class instead an anonymous class, you can > just > >> subclass FFIExternalValueHolder: > >> > >> FFIExternalValueHolder subclass: #MyIntPtr > >> > >> and then implement typeDecl class method > >> > >> MyIntPtr class>>typeDecl > >> ^ ?int' > >> > >> and this will work as the anonymous class > > > > The second option is definitely what I want. > > Personally my option would be to put my types in a class pool and use > them, not to extendâ¦ > but option is there so you can choose what you want :) > > > I am trying to expose a function returning several ints, as in > SDL2>>mouseStateX: y: (excluding the possibility to return a Point). > > However I would rather not define my own int holder, can't we have > generic holders to rely on? > > I will not add for the moment that predefined types value holdersâ¦ We > would need to add one for each type we support to be consistent, and > document it, and add tests. > And btwâ¦ you do have a generic holderâ¦ is just that you need to refine it > to what you want :) > You could always use a ByteArray and took values later (some functions in > Athens do it like that). The advantage of this approach (using plain > ByteArrays) is that you do not need to change function signature at the > cost of needing to do manually what the value holder does for you. > Hi Esteban, is this the way it should be done for Strings ? For example, old NBOpenGL had this Windows method to get the Window Title: getWindowText: hWnd buffer: lpString bufferSize: nMaxCount <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^self nbCall: #(int GetWindowTextA(HWND hWnd, char* lpString, int nMaxCount)) module: #user32 called as: getWindowText | len str | str := ByteString new: 1000. len := self getWindowText: self buffer: str bufferSize: 1000. ^ str first: len. When I just modify the ffiCall to getWindowText: hWnd buffer: lpString bufferSize: nMaxCount ^self ffiCall: #(int GetWindowTextA(HWND hWnd, char* lpString, int nMaxCount)) module: #user32 I get just an empty String. But If I call it with: | len str | str := ByteArray new: 1000. len := self getWindowText: self buffer: str bufferSize: 1000. ^ String fromByteArray: (str first: len). I get the real string text. Is this the way to go? > > My advise is that you go with what you need, we can consider add > predefined value holders later. > > Esteban > > > > > Thibault > > > > >

April 13, 2016

[ANN] General WebBrowser package for Pharo4 and Pharo 5 onwards

by Torsten Bergmann

Hi, Some of you may know or use "ExternalWebbrowser" (maintained in the past by me, started back in the times right after Squeak and based on FFI), also there was an "ExternalWebbrowser2" fork from Sean later. First project got outdated with transition to NB, the second one stopped working for Pharo 5 due to the transition from NativeBoost (NB) to Universal Foreign Function Interface (UFFI). Two projects and now the broken code created a little bit a mess again in finding an easy way in opening an external webbrowser from Pharo. Updating my "ExternalWebbrowser" would easily bring confusion to newbies who thing "ExternalWebbrowser2" is newer. Having a an "ExternalWebbrowser3" would be silly too. So I decided to fix all this by providing a general "WebBrowser" package which now should solve the issue of easily opening an external webbrowser once and for all for primary platforms (Unix/Mac/Windows). The simple design allows to add also other platforms later if necessary. I based it for Pharo 4 on NB and Pharo 5 onwards on the new UFFI - so YES you can use it in both Pharo versions uniformely and the same way - which should simplify things now again. # Project page/Repository http://www.smalltalkhub.com/#!/~TorstenBergmann/WebBrowser # Description General and platform independent WebBrowser access for Pharo 4.0 onwards based on NativeBoost, for Pharo 5.0 onwards based on UFFI - Mac - Unix (Linux flavours) - Windows # Usage WebBrowser openOn: 'http://www.pharo.org' # Installation You can load it either from Configuration Browser (Pharo 4), Catalog/directly by typing "WebBrowser" into Spotter (Pharo 5 onwards) or with the following load expression: Metacello new smalltalkhubUser: 'TorstenBergmann' project: 'WebBrowser'; configuration: 'WebBrowser'; load # Other If you want to reference it in own configs note that version 0.1.0 is for Pharo 4 while 0.2.0 and following is for Pharo 5 onwards. Bye T.

April 13, 2016

Re: [Pharo-users] SQLite bridge crashed Pharo 5.

by stepharo

but you can have your objects in memory and you do not have to blindly print everything or put everything in a table. with moose sometimes we have 600K objects in an array. I think that we need more clever stream to filter what we want to load. Le 13/4/16 02:49, Offray Vladimir Luna CÃ¡rdenas a Ã©crit : > Hi, > > On 12/04/16 16:51, Stephan Eggermont wrote: >> On 12/04/16 22:44, Offray Vladimir Luna CÃ¡rdenas wrote: >>> I'm working with visualizations a external dataset which contains 270k >>> records. So the best strategy seems to bridge pharo with SQLite to keep >>> requirements low while using Roassal to visualize aggregated >>> information >>> that is obtained from querying the database. >> >> It won't fit in image? >> > > I tried with RTTabTable and NeoCVS but they can not load the data. I > made a test drawing 150k points and the image starts to lag and trying > to query the data becomes inefficient compared to query the data on > SQLite. For the moment I'll export the query results to CVS, but I'll > hope to have the SQLite bridge working soon. > > Offray > >

April 13, 2016

Re: [Pharo-users] First impressions, was About Box

by stepharo

Le 13/4/16 06:48, John Pfersich a Ã©crit : > >> On Apr 12, 2016, at 10:51, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >>> On Mon, Apr 11, 2016 at 09:02:52PM +0200, Serge Stinckwich wrote: >>> Thank you. I was talking about your experience with Pharo :-) >>> But your description is nice also. >> Ahh, right, sorry about that. >> >> Pharo 5.0 first impressions from someone coming from VW2.5... >> >> I'm already a fan of Smalltalk and its development environment. I've >> only spent a few hours working with Pharo (it's my hobby, with not >> nearly as much time as I would like): >> >> * I read the first few chapters of Pharo by Example as an introduction >> to Pharo. >> * The browser, debugger and basic inspectors are all familiar enough >> that I was able to work with them without any issues. >> * I'm glad that being able to run headless mode is easy, as I'd like to >> use Pharo for scripting. >> * The addition of Montacello / Metacello / Gofer and SUnit are the >> biggest improvements I've noticed so far. I wish I had these 20 years >> ago. >> * I've only played with the MessageFlow Browser a little, but I think it >> will be one of my go-to tools. >> * I'm still getting used to the idea of the entire ST environment being >> in a single OS window, but at the moment I think I prefer VW's >> approach where each ST window is a OS window, as it makes it easier to >> work with other applications, e.g. if I want to look at an email or >> web page while working within ST. >> >> I only have one suggested improvement so far (assuming it doesn't >> already exist and I just haven't found it yet)... When searching for >> packages on SqueakSource / SmalltalkHub etc. it isn't clear to me how >> much confidence I can have in any given package, which is really useful >> if there are multiple packages providing similar functionality. >> >> The Arch Linux model seems pretty good to me. Official packages are in >> the core or extra repositories, which matches what is included in the >> Pharo image. The next level is a community repository, which contains >> packages maintained by Trusted Users. General users can be confident >> that these packages will be kept up to date. The last level is the User >> Repository (AUR), which anyone can contribute to. The AUR includes a >> comment section and vote count, and general users can add or remove >> their vote. > I'd like to see something like this too. > us too first you have some pharo extras packages second favor package with tests third we have been working on quality rules and quality rule false positive management so you can run the tests and run the rules now we will start to work on package validation to produce a kind of "validated" distribution of pharo packages. Stef

April 13, 2016

Re: [Pharo-users] First impressions, was About Box

by John Pfersich

> On Apr 12, 2016, at 10:51, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> On Mon, Apr 11, 2016 at 09:02:52PM +0200, Serge Stinckwich wrote: >> Thank you. I was talking about your experience with Pharo :-) >> But your description is nice also. > > Ahh, right, sorry about that. > > Pharo 5.0 first impressions from someone coming from VW2.5... > > I'm already a fan of Smalltalk and its development environment. I've > only spent a few hours working with Pharo (it's my hobby, with not > nearly as much time as I would like): > > * I read the first few chapters of Pharo by Example as an introduction > to Pharo. > * The browser, debugger and basic inspectors are all familiar enough > that I was able to work with them without any issues. > * I'm glad that being able to run headless mode is easy, as I'd like to > use Pharo for scripting. > * The addition of Montacello / Metacello / Gofer and SUnit are the > biggest improvements I've noticed so far. I wish I had these 20 years > ago. > * I've only played with the MessageFlow Browser a little, but I think it > will be one of my go-to tools. > * I'm still getting used to the idea of the entire ST environment being > in a single OS window, but at the moment I think I prefer VW's > approach where each ST window is a OS window, as it makes it easier to > work with other applications, e.g. if I want to look at an email or > web page while working within ST. > > I only have one suggested improvement so far (assuming it doesn't > already exist and I just haven't found it yet)... When searching for > packages on SqueakSource / SmalltalkHub etc. it isn't clear to me how > much confidence I can have in any given package, which is really useful > if there are multiple packages providing similar functionality. > > The Arch Linux model seems pretty good to me. Official packages are in > the core or extra repositories, which matches what is included in the > Pharo image. The next level is a community repository, which contains > packages maintained by Trusted Users. General users can be confident > that these packages will be kept up to date. The last level is the User > Repository (AUR), which anyone can contribute to. The AUR includes a > comment section and vote count, and general users can add or remove > their vote. I'd like to see something like this too. > > Hope I haven't ruffled too many feathers... > > Thanks! > Alistair >

April 13, 2016