May 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Idea of searcheability of Pharo project on git

by Esteban Lorenzano

this search: https://github.com/search?q=useCypressPropertiesFile&ref=advsearch&type=Code <https://github.com/search?q=useCypressPropertiesFile&ref=advsearch&type=Code> will retrieve all projects in github using cypress files format, which is fairly true are mostly Pharo compatible. Or cypress compatible, but cypress is used by the same groups that before committed packages on sthub, ss3 and ss, so is more or less the same :) btw, there are already more than 5k repos. But for some reason some repos appear doubleâ¦ Well, this query can be improved for sure :) We can do a small tool to list/query repositories inside pharo too. But in general, none of this will avoid the need of having a tool like the catalog: a central repository of projects. cheers, Esteban > On 13 May 2017, at 09:55, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 13/05/2017 Ã 09:46, Stephane Ducasse a Ã©crit : >> I was more talking about the other projects :) >> the projects of everybody because for Pharo itself it is more or less easy. > > A pharo contributors organisation, an umbrella for all projects (or forks) that one want to associate with Pharo. > > Thierry > >> On Sat, May 13, 2017 at 9:32 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 13/05/2017 Ã 09:01, Stephane Ducasse a Ã©crit : >> >> Hi guys >> >> right now many people publish their software on SmalltalkHUB, >> SS3 and >> Squeaksource >> and this is handy to find something. >> >> >> I hope that we will release soon the package repository that >> christophe >> was developing but >> now I'm wondering if we as a community should follow a pattern >> to help? >> >> git freaks do you have suggestions >> >> >> A github organization for Pharo and for contributors. Like >> SquareBraquetsAssociates. >> >> Thierry >> >> >> >> Stef >> >> >> >> > >

May 13, 2017

Re: [Pharo-dev] Missing plugins to make the vmProfiler work

by Nicolas Cellier

2017-05-12 22:32 GMT+02:00 <csrabak(a)bol.com.br>: > On 12 May 2017 07:40:49 -0700, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > Hi Cesar, > > [snipped] > > Hi Eliot, > > > > I'm on this vital industry for 45+ years and I already learned > > > that words and names have usages and except when standarized via > > > certains bodies aimed specifically the meaning can vary even > > > within the same realm of the art. > > > That written, and without attempting to start a semantic > > > discussion, however feeling a contribution may be useful, I would > > > say that the 'levels' one and two described above would better > > > called "modules" instead of plugins. > > > In my way of understanding this non mother tongue "compile time > > > plugins" seem to be more a figure of speech than the offering of > > > 'plugability' which plugins offer, or perhaps, in my humble > > > perception ought to offer. > > > Also, I think it would be less surprising for most people when > > > exposed to the subject (module == compiling, plugin == run time). > > > +1. I think the system designers agreed with you because the way to > > find out what plugins are available is > > Smalltalk listLoadedModules > > > Thank you Eliot! > > You'll not believe the number of times I typed and backtyped about > listLoadedModules! > > I keep thinking if I was not being too 'pushy' on my stance. . . :-) > > If after a serene consideration of the group and finding that would be > right direction for Pharo, we can consider breaking this method in > two: > > Smalltalk listLoadedModules > > Smalltalk listLoadedPlugins > > And in the future have this info exposed in the World menus. > > Regards, > -- > Cesar Rabak > > But from the image POV is there any difference between an internal module and an external plugin ? If none, what would justify such split ? Additional complexity has to pay back or die.

May 13, 2017

Re: [Pharo-dev] Idea of searcheability of Pharo project on git

by Thierry Goubier

Le 13/05/2017 Ã 09:46, Stephane Ducasse a Ã©crit : > I was more talking about the other projects :) > the projects of everybody because for Pharo itself it is more or less easy. A pharo contributors organisation, an umbrella for all projects (or forks) that one want to associate with Pharo. Thierry > On Sat, May 13, 2017 at 9:32 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Le 13/05/2017 Ã 09:01, Stephane Ducasse a Ã©crit : > > Hi guys > > right now many people publish their software on SmalltalkHUB, > SS3 and > Squeaksource > and this is handy to find something. > > > I hope that we will release soon the package repository that > christophe > was developing but > now I'm wondering if we as a community should follow a pattern > to help? > > git freaks do you have suggestions > > > A github organization for Pharo and for contributors. Like > SquareBraquetsAssociates. > > Thierry > > > > Stef > > > >

May 13, 2017

Re: [Pharo-dev] Idea of searcheability of Pharo project on git

by Stephane Ducasse

I was more talking about the other projects :) the projects of everybody because for Pharo itself it is more or less easy. On Sat, May 13, 2017 at 9:32 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 13/05/2017 Ã 09:01, Stephane Ducasse a Ã©crit : > >> Hi guys >> >> right now many people publish their software on SmalltalkHUB, SS3 and >> Squeaksource >> and this is handy to find something. >> >> >> I hope that we will release soon the package repository that christophe >> was developing but >> now I'm wondering if we as a community should follow a pattern to help? >> >> git freaks do you have suggestions >> > > A github organization for Pharo and for contributors. Like > SquareBraquetsAssociates. > > Thierry > > >> >> Stef >> > > >

May 13, 2017

Re: [Pharo-dev] Idea of searcheability of Pharo project on git

by Thierry Goubier

Le 13/05/2017 Ã 09:01, Stephane Ducasse a Ã©crit : > Hi guys > > right now many people publish their software on SmalltalkHUB, SS3 and > Squeaksource > and this is handy to find something. > > > I hope that we will release soon the package repository that christophe > was developing but > now I'm wondering if we as a community should follow a pattern to help? > > git freaks do you have suggestions A github organization for Pharo and for contributors. Like SquareBraquetsAssociates. Thierry > > > Stef

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Thierry Goubier

Le 13/05/2017 Ã 08:58, Stephane Ducasse a Ã©crit : > My gut feeling is that it will be better not to mix git and MC. It is easy to make MC compatible with Git. It wasn't that hard in the past, but needed a community effort (MC being a core part of the system). Now, with the infrastructure underway (libgit, git fast-import) it looks very easy to implement. Thierry > > > On Fri, May 12, 2017 at 11:09 PM, Oleksandr Zaytsev > <olk.zaytsev(a)gmail.com <mailto:olk.zaytsev@gmail.com>> wrote: > > Hello > > Two days ago I was trying to send the slice with my fix to PolyMath > using Monticello. But the version number got set to 1494471195. > Today I realized that all the packages to which I commit are > numbered like that. > > Cyril Ferlicot explained to me that this happens when I mix git and > Monticello commits. He suggested that I use a separate image for > committing to GitHub, or file out/file in if there is a lot of > changes to commit. > > Can this be considered a bug? Should I report it? > > I think it would be causing problems for many people. > > Oleks > >

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Max Leske

> On 12 May 2017, at 23:09, Oleksandr Zaytsev <olk.zaytsev(a)gmail.com> wrote: > > Hello > > Two days ago I was trying to send the slice with my fix to PolyMath using Monticello. But the version number got set to 1494471195. Today I realized that all the packages to which I commit are numbered like that. > > Cyril Ferlicot explained to me that this happens when I mix git and Monticello commits. He suggested that I use a separate image for committing to GitHub, or file out/file in if there is a lot of changes to commit. > > Can this be considered a bug? Should I report it? > > I think it would be causing problems for many people. Yes, please open an issue on the GitHub issue tracker (https://github.com/pharo-vcs/iceberg <https://github.com/pharo-vcs/iceberg>). > > Oleks

May 13, 2017

Idea of searcheability of Pharo project on git

by Stephane Ducasse

Hi guys right now many people publish their software on SmalltalkHUB, SS3 and Squeaksource and this is handy to find something. I hope that we will release soon the package repository that christophe was developing but now I'm wondering if we as a community should follow a pattern to help? git freaks do you have suggestions Stef

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Stephane Ducasse

My gut feeling is that it will be better not to mix git and MC. On Fri, May 12, 2017 at 11:09 PM, Oleksandr Zaytsev <olk.zaytsev(a)gmail.com> wrote: > Hello > > Two days ago I was trying to send the slice with my fix to PolyMath using > Monticello. But the version number got set to 1494471195. Today I realized > that all the packages to which I commit are numbered like that. > > Cyril Ferlicot explained to me that this happens when I mix git and > Monticello commits. He suggested that I use a separate image for committing > to GitHub, or file out/file in if there is a lot of changes to commit. > > Can this be considered a bug? Should I report it? > > I think it would be causing problems for many people. > > Oleks >

May 13, 2017

Re: [Pharo-dev] [ANN] Pompeii Volcanic Graphics, a mesh based 2D graphics API

by Stephane Ducasse

Esteban is preparing the release of Pharo 60 but I'm quite sure that he will integrate your PR for SDL20 and OSWindow. OSWindow is too important for us :) Now we need to move everything to use it but our plates were rather full. Stef On Sat, May 13, 2017 at 8:50 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi ronie > > This is super cool. I would prefer Volcano to Pompeii because lot of > people died at pompeii but it the dead in Pharo are the old Morphs this is > ok for me :) > About the back end, this is really good to have multiple back-ends for > Bloc. > > Stef > > > On Sat, May 13, 2017 at 1:55 AM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: > >> Hi Alex, >> >> This is great! >>> Do you know whether Pompeii can be used by Bloc? >>> >> I do not know. If the Bloc people pointed me to the places that have to >> be modified, and if there are willing to have yet another backend, then I >> am willing to try adding the backend for Bloc. >> >> Best regards, >> Ronie >> >> 2017-05-12 20:01 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> >>> Hi Ronie, >>> >>> This is great! >>> Do you know whether Pompeii can be used by Bloc? >>> >>> Alexandre >>> >>> >>> > On May 12, 2017, at 6:26 PM, Ronie Salgado <roniesalg(a)gmail.com> >>> wrote: >>> > >>> > Hello, >>> > >>> > I am releasing a first version of a new 2D graphics API that I am >>> making for Pharo, using OpenGL. >>> > >>> > <Captura de pantalla de 2017-05-12 18-23-03.png> >>> > <Captura de pantalla de 2017-05-12 18-24-30.png> >>> > >>> > http://smalltalkhub.com/#!/~ronsaldo/PompeiiGraphics >>> > https://youtu.be/emE6_1RpAo8 >>> > >>> > This 2D graphics API is not vectorial based becase it does not use SVG >>> style paths. This API is triangle mesh based, so it is more friendlier with >>> the GPU than Athens or Sparta. >>> > >>> > With this API I did a basic gui toolkit, with only two widgets: >>> buttons and label. I did this Widget toolkit to not mess with Bloc, and >>> because I need something relatively stable for the Woden 2 level editor. >>> For now, I am leaving this widget toolkit mostly as a demo. Hopefully it is >>> possible to make Bloc backend using this API. >>> > >>> > During the process of making this API, I had to fix several bugs with >>> OSWindow, and bugs in the interaction between OSWindow and OpenGL. The >>> biggest problem was a race condition between the creation of an OSWindow >>> using SDL2, and the events (such as Expose) that are sent to the just >>> created Window. >>> > >>> > As for Mac OS X, OSWindow is out of service until a pull request ( >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/138 ) gets >>> integrated into the VM. >>> > >>> > Best regards, >>> > Ronie >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> >

May 13, 2017