- Pharo-dev - lists.pharo.org

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

by Yuriy Tymchuk

Okâ¦ Iâm pretty sure Iceberg did not delete my MC metadata. Maybe I used it too long ago for my project > On 13 May 2017, at 15:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Iâm not a bit expert, but if you donât use âmetadatalessâ format everything works fine with monticello. I.e. each git commit contains all the mc history. > > yes, but with iceberg we did another choice: we force metadataless and do not keep compatibility with monticello. > this is like that by design: keeping the metadata was too much noise and generated a lot of conflicts we donât want. > > So, using iceberg is not using git as âjust another repository format as http, ftp, etc.â. > If you want to keep both versions, then you need to save in mc format then save again in iceberg (or viceversa). > > Esteban > >> >> Uko >> >>> On 13 May 2017, at 09:28, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> 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 Esteban Lorenzano

> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Iâm not a bit expert, but if you donât use âmetadatalessâ format everything works fine with monticello. I.e. each git commit contains all the mc history. yes, but with iceberg we did another choice: we force metadataless and do not keep compatibility with monticello. this is like that by design: keeping the metadata was too much noise and generated a lot of conflicts we donât want. So, using iceberg is not using git as âjust another repository format as http, ftp, etc.â. If you want to keep both versions, then you need to save in mc format then save again in iceberg (or viceversa). Esteban > > Uko > >> On 13 May 2017, at 09:28, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> 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] Idea of searcheability of Pharo project on git

by Esteban Lorenzano

> On 13 May 2017, at 15:26, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi dale > > christophe developed something like that and this is based on cargo metadata. yes, and ultimately this will be needed to have a good catalog. > > Stef > > > On Sat, May 13, 2017 at 3:04 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: > Steph, > > As Thierry mentions you should create an umbrella project for Pharo where you can maintain a list of projects contributed by users --- something like I've done for GsDevKit_home[1]. > > I strongly suggest that you use a "project load spec object"[2][3] as the unit of registration for your projects. In addition to the Metacello load instructions the "project load spec" can maintain a bunch of meta data about the project. > > The pharo image can scan the projects listed (similar to what you do with the Category Browser - I think) or better yet, the developer can make a local clone of the project site in a well-known location and then all images can look up projects in this the local clone and avoid having to hit the network to build the project list ... > > Take a look at the video or slides for my "Dangerous Liaisons: Smalltalk, files, and git"[4] for more details ... and of course I'm willing to discuss additional details/ideas over skype or email. > > Dale > > [1] http://gsdevkit.github.io/GsDevKit_home/ <http://gsdevkit.github.io/GsDevKit_home/> > > [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston <https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston> > > [3] https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston <https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston> > > [4] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git <http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git> > > > > On 5/13/17 12:01 AM, Stephane Ducasse wrote: > 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] Idea of searcheability of Pharo project on git

by Esteban Lorenzano

> On 13 May 2017, at 15:04, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Steph, > > As Thierry mentions you should create an umbrella project for Pharo where you can maintain a list of projects contributed by users --- something like I've done for GsDevKit_home[1]. there is already an umbrella project for pharo which is âpharo-projectâ. we also promote some othe rmeta projects under the âpharoâ umbrella. pharo-project pharo-graphics pharo-vcs pharo-nosql and probably some others will emerge. the reason why we donât concentrate all on one is just organisational, and we could review that on the future. > > I strongly suggest that you use a "project load spec object"[2][3] as the unit of registration for your projects. In addition to the Metacello load instructions the "project load spec" can maintain a bunch of meta data about the project. > > The pharo image can scan the projects listed (similar to what you do with the Category Browser - I think) or better yet, the developer can make a local clone of the project site in a well-known location and then all images can look up projects in this the local clone and avoid having to hit the network to build the project list ... > > Take a look at the video or slides for my "Dangerous Liaisons: Smalltalk, files, and git"[4] for more details ... and of course I'm willing to discuss additional details/ideas over skype or email. > > Dale > > [1] http://gsdevkit.github.io/GsDevKit_home/ > > [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston > > [3] https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston > > [4] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git > > > On 5/13/17 12:01 AM, Stephane Ducasse wrote: >> 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 Oleks

So basically, this is not a bug, but the way Iceberg and Monticello are built? And there is no point in reporting it because it can't be fixed? Oleks -- View this message in context: http://forum.world.st/Git-breaks-Monticello-s-version-numbers-tp4946939p494… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 13, 2017

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

by Esteban Lorenzano

Vectorial Graphics are CPU intensive, and is arguably if it is a good solution for rendering IDEs. Using OpenGL 2D allows us to have another possibility, that will perform better in some scenarios. thanks Ronie for such a great work! Esteban > On 13 May 2017, at 15:19, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Yes, Iâm just not aware how Cairo and Moz2D are rendering the things the we ask them to. Thatâs why I wanted more info :) > >> On 13 May 2017, at 13:29, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> The cool thing is that the rendering can happen on the GPU (through OpenGL), which is the fastest you can get for rendering . >> >> So, the current renderings are not the point. The point is the possibilities that are open once we have access to rendering 2D through OpenGL. >> >> Cheers, >> Doru >> >> >> >>> On May 13, 2017, at 1:22 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Hey guys, can someone explain me why this is cool? :) >>> Because the examples just have basic shapes with gradients & similar and AFAIK you could do that for a long time with Pharo and other technologies. Does Pompei mean that we can render complex graphics super fast? Is there an example for that? >>> >>> Uko >>> >>>> On 13 May 2017, at 08:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> 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 >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "What we can governs what we wish." >> >> >> >> >> > >

May 13, 2017

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

by Cyril Ferlicot D.

On 13/05/2017 09:01, Stephane Ducasse wrote: > 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 Hi, In github you have the possibility to search by tags (the little chips under the description of a project). For this you need to add "topic:pharo" in the search. https://github.com/search?utf8=%E2%9C%93&q=topic%3Apharo&type= Also github detect the language of the repo and you can search with the "language:Smalltalk" tag in the search. https://github.com/search?utf8=%E2%9C%93&q=language%3ASmalltalk&type=Reposi… This is only for github bug I think that most of the open source projects will be on github. And some on bitbucket and gitlab. But I think they should have some search like github. And we can do nothing for self hosted git repositories I think :) -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

May 13, 2017

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

by Stephane Ducasse

Hi dale christophe developed something like that and this is based on cargo metadata. Stef On Sat, May 13, 2017 at 3:04 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Steph, > > As Thierry mentions you should create an umbrella project for Pharo where > you can maintain a list of projects contributed by users --- something like > I've done for GsDevKit_home[1]. > > I strongly suggest that you use a "project load spec object"[2][3] as the > unit of registration for your projects. In addition to the Metacello load > instructions the "project load spec" can maintain a bunch of meta data > about the project. > > The pharo image can scan the projects listed (similar to what you do with > the Category Browser - I think) or better yet, the developer can make a > local clone of the project site in a well-known location and then all > images can look up projects in this the local clone and avoid having to hit > the network to build the project list ... > > Take a look at the video or slides for my "Dangerous Liaisons: Smalltalk, > files, and git"[4] for more details ... and of course I'm willing to > discuss additional details/ideas over skype or email. > > Dale > > [1] http://gsdevkit.github.io/GsDevKit_home/ > > [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston > > [3] https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston > > [4] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git > > > > On 5/13/17 12:01 AM, Stephane Ducasse wrote: > >> 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] [ANN] Pompeii Volcanic Graphics, a mesh based 2D graphics API

by Yuriy Tymchuk

Yes, Iâm just not aware how Cairo and Moz2D are rendering the things the we ask them to. Thatâs why I wanted more info :) > On 13 May 2017, at 13:29, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > The cool thing is that the rendering can happen on the GPU (through OpenGL), which is the fastest you can get for rendering . > > So, the current renderings are not the point. The point is the possibilities that are open once we have access to rendering 2D through OpenGL. > > Cheers, > Doru > > > >> On May 13, 2017, at 1:22 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hey guys, can someone explain me why this is cool? :) >> Because the examples just have basic shapes with gradients & similar and AFAIK you could do that for a long time with Pharo and other technologies. Does Pompei mean that we can render complex graphics super fast? Is there an example for that? >> >> Uko >> >>> On 13 May 2017, at 08:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> 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 >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "What we can governs what we wish." > > > > >

May 13, 2017

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

by Dale Henrichs

Steph, As Thierry mentions you should create an umbrella project for Pharo where you can maintain a list of projects contributed by users --- something like I've done for GsDevKit_home[1]. I strongly suggest that you use a "project load spec object"[2][3] as the unit of registration for your projects. In addition to the Metacello load instructions the "project load spec" can maintain a bunch of meta data about the project. The pharo image can scan the projects listed (similar to what you do with the Category Browser - I think) or better yet, the developer can make a local clone of the project site in a well-known location and then all images can look up projects in this the local clone and avoid having to hit the network to build the project list ... Take a look at the video or slides for my "Dangerous Liaisons: Smalltalk, files, and git"[4] for more details ... and of course I'm willing to discuss additional details/ideas over skype or email. Dale [1] http://gsdevkit.github.io/GsDevKit_home/ [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston [3] https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston [4] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git On 5/13/17 12:01 AM, Stephane Ducasse wrote: > 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