- Pharo-users - lists.pharo.org

Re: [Pharo-users] Eating your own dog food (Site/Blog)

by Yuriy Tymchuk

When are you going to be in Lviv? > On 08 Apr 2015, at 08:32, stepharo <stepharo(a)free.fr> wrote: > > I started to work on using pillar to do that but nothing ready for people to use. > I will work on it at Lviv or during my vacations just after. > I want to use it for my website. Right now parts of it are automatically generated from Pharo. > > Stef > > Le 7/4/15 10:56, Yuriy Tymchuk a Ã©crit : >> Oh, I knew that there was a discussion about that, but couldnât find where. >> >> Still, is anybody else using Marina except for Pharo website? >> >> Uko >> >> >> >>> On 07 Apr 2015, at 10:45, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> >>> >>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: >>> >>>> if I want to create a site/blog in pharoâ¦ What do I use? I know that >>>> there is Pier, but when you check its webpage, the last update is in >>>> 2011. Pharo website is built with Marina, but when I check the repo, >>>> the last commit was done by me and it was 2 month ago. Will Marina >>>> continue to evolve? And is anyone else using Marina? >>> >>> http://forum.world.st/Any-framework-to-create-a-blog-over-seaside-td4810615… >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." --Winston Churchill >>> >> >> > >

April 8, 2015

Re: [Pharo-users] Eating your own dog food (Site/Blog)

by Christophe Demarey

There is a plan to have pillar rendering with TextModel. I don't think it will support the full pillar syntax. Le 8 avr. 2015 Ã 11:16, Norbert Hartl a Ã©crit : > What you are after? A static site generator or a dynamic engine? Btw. what do you use to render pillar inside the image to something readable? > > Norbert > >> Am 08.04.2015 um 08:32 schrieb stepharo <stepharo(a)free.fr>: >> >> I started to work on using pillar to do that but nothing ready for people to use. >> I will work on it at Lviv or during my vacations just after. >> I want to use it for my website. Right now parts of it are automatically generated from Pharo. >> >> Stef >> >> Le 7/4/15 10:56, Yuriy Tymchuk a Ã©crit : >>> Oh, I knew that there was a discussion about that, but couldnât find where. >>> >>> Still, is anybody else using Marina except for Pharo website? >>> >>> Uko >>> >>> >>> >>>> On 07 Apr 2015, at 10:45, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>>> >>>> >>>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: >>>> >>>>> if I want to create a site/blog in pharoâ¦ What do I use? I know that >>>>> there is Pier, but when you check its webpage, the last update is in >>>>> 2011. Pharo website is built with Marina, but when I check the repo, >>>>> the last commit was done by me and it was 2 month ago. Will Marina >>>>> continue to evolve? And is anyone else using Marina? >>>> >>>> http://forum.world.st/Any-framework-to-create-a-blog-over-seaside-td4810615… >>>> -- >>>> Damien Cassou >>>> http://damiencassou.seasidehosting.st >>>> >>>> "Success is the ability to go from one failure to another without >>>> losing enthusiasm." --Winston Churchill >>>> >>> >>> >> >> > >

April 8, 2015

Re: [Pharo-users] Eating your own dog food (Site/Blog)

by Norbert Hartl

What you are after? A static site generator or a dynamic engine? Btw. what do you use to render pillar inside the image to something readable? Norbert > Am 08.04.2015 um 08:32 schrieb stepharo <stepharo(a)free.fr>: > > I started to work on using pillar to do that but nothing ready for people to use. > I will work on it at Lviv or during my vacations just after. > I want to use it for my website. Right now parts of it are automatically generated from Pharo. > > Stef > > Le 7/4/15 10:56, Yuriy Tymchuk a Ã©crit : >> Oh, I knew that there was a discussion about that, but couldnât find where. >> >> Still, is anybody else using Marina except for Pharo website? >> >> Uko >> >> >> >>> On 07 Apr 2015, at 10:45, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> >>> >>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: >>> >>>> if I want to create a site/blog in pharoâ¦ What do I use? I know that >>>> there is Pier, but when you check its webpage, the last update is in >>>> 2011. Pharo website is built with Marina, but when I check the repo, >>>> the last commit was done by me and it was 2 month ago. Will Marina >>>> continue to evolve? And is anyone else using Marina? >>> >>> http://forum.world.st/Any-framework-to-create-a-blog-over-seaside-td4810615… >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." --Winston Churchill >>> >> >> > >

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Martin BÃ¤hr

Excerpts from Thierry Goubier's message of 2015-04-08 10:11:44 +0200: > > As I've said to Thierry some time ago in different thread, I would be > > interested in idea of having everything on disk side and Pharo would only > > somehow refresh it's content (just like a Java IDE / text editor would). > > But that may be a lot o work so I can only dream about it, as nobody has > > time for that (me included). > Well, as I said elsewhere, Smalltalk doesn't work like that: code has to be > lived in the image for most tools to work properly... it doesn't really > have an "editor of file" mindset, but an "object inspector" mindset. the interesting thing is that i don't think git is the problem here. a git repo does not need to have a working tree. smalltalk git tools could read the code directly from git using git-fast-export and write them with git-fast-import the effect would be that the working tree is now only in the smalltalk image, and git would be a pure storage of history. any use of external tools on the repo would happen on a clone and be pushed into the repo that smalltalk uses. that would however be a complete break with filetree. (it could still create compatible structures, it just could not use its code to read and write) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Thierry Goubier

2015-04-08 8:47 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > I thnk that rather than focus on the disk format which I hardly ever >> actually look at ... that folks should be looking at tools support (like >> Thierry) ... this is where the real work needs to happen ... good tools can >> hide the disk fomat completely so why does the disk format matter ... > > I am personally not really a fan of this; I've been using git for a while > and I am perfectly content with using command line on the disk (maybe I'm > rare breed); I have yet to see a GUI/tool that would come even close to the > power of command line, but I've been using Linux for a long time. > Agreed and this is in that spirit I did GitFileTree. Dale went a bit further and even integrated the git command line access inside smalltalk via CommandShell... so that you get the best of both worlds without leaving your beloved Smalltalk :) > As I've said to Thierry some time ago in different thread, I would be > interested in idea of having everything on disk side and Pharo would only > somehow refresh it's content (just like a Java IDE / text editor would). > But that may be a lot o work so I can only dream about it, as nobody has > time for that (me included). > Well, as I said elsewhere, Smalltalk doesn't work like that: code has to be lived in the image for most tools to work properly... it doesn't really have an "editor of file" mindset, but an "object inspector" mindset. What we're looking at in another thread is how to emulate that live object approach over dead files, and, thinking of it, I'm not sure we will succeed well. In short, what you want may never work properly because it is not how it should be conceptualized. > > But to bottom line this thread (for me at least, because I'm getting lost): > 1. methodProperties.json provide compatibility for FileTree, so I don't > want to get rid of it (for now) > 2. the large amount of file changes is probably a bug (I'll try to be more > observant about the commits in the future and hopefully some pattern will > emerge.) > 3. I shouldn't want to break things for now at least > 4. more people are starting to work on Git > 5. I need to learn about FileTree at some point if I want to contribute > and experiment with (my) ideas (which won't be soon as I'm preparing for my > finals) > Please ask around for 5. It is valuable to have to expose what we already know. Thierry > > Thanks for all your answers. > > Peter > > On Wed, Apr 8, 2015 at 7:24 AM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> Le 08/04/2015 02:05, Dale Henrichs a Ã©crit : >> >>> Peter, >>> >>> That looks like a bug in the FileTree writer ... wiht one method change >>> there should have been only one method property file change ... >>> >> >> Yes, I'd agree. This is surprising. >> >> Unless you had been loading that package via another repository / another >> version / another branch before in the same image? >> >> MCMethodDefinition has a cache which consider equals methods with >> different timestamps, and, in that case, it would carry the timestamps of >> the previous version, and writing those upon save instead of the originals. >> >> Peter and Sean, >>> >>> If you are interested in contributing code/bugfixes to FileTree, I will >>> welcome pull requests ... As I have mentioned in several posts today, I >>> do not have the time to fiddle with changes to the FileTree format >>> myself, but I welcome contributions. >>> >>> Damien has started work on an updated version of the FileTree format[2]. >>> >>> I have threatened in the past to add an option to a repository that >>> would eliminate the need to store monticello meta data ... Damien is >>> working on "starting from scratch" on the new format, because the >>> current implementation supports 4-5 different FileTree formats. Damien's >>> work could be leveraged to add an "optional Monticello meta data" option >>> to FileTree and if your SCM (like git) gives you per method history with >>> the proper tools you can leverage that information.. >>> >> >> I would say this could be a reasonable possibility, in that you could >> have two modes of compatibility: >> >> - Complete filetree compatibility for gitfiletree: the current situation, >> with properties and version written to disk. >> >> - Partial filetree compatibility, where that metadata isn't written and >> you rely on gitfiletree to recreate it to export as .mcz. >> >> Partial compatibility has two effects, which need to be considered. When >> using github:// or bitbucket:// urls, filetree will be used and your >> packages will end up having no version number (except .1?), no author, no >> timestamps for methods, etc... And the second one is that, if you clone a >> mcz inside the gitfiletree repository, the mcz ancestry of versions and >> author timestamps on methods will be lost, which is something you may not >> want. >> >> Thierry >> >> As I ranted in another post ... changing the disk format is the easy >>> part ... building and maintaining tools for the 4-5 different Smalltalk >>> dialects is a different matter ... >>> >>> Dale >>> >>> [1] https://github.com/dalehenrich/filetree/issues >>> [2] https://github.com/dalehenrich/filetree/issues/144 >>> On 04/07/2015 04:38 PM, Peter UhnÃ¡k wrote: >>> >>>> Yeah, I do use the MergeDriver and it saved me a lot of headache, but >>>> when I see things like this >>>> >>>> https://github.com/dynacase/dynacase/commit/ >>>> 90141d63bfdd433e51a768c2191e035b76c5da83 >>>> >>>> where one five lines long method generated 14 file changes with 180 >>>> additions and 172 deletions... it makes the log on github and pull >>>> requests incredibly messy. >>>> >>>> I don't want to cut branch under myself if I were to remove the >>>> properties file. So my question now is: how hard would it be to >>>> regenerate those files? >>>> >>>> Or maybe if it was moved to some metadirectory. This reminds me a bit >>>> of svn which polluted the whole folder tree with .svn files everywhere. >>>> >>>> Peter >>>> >>>> >>>> >>>> On Wed, Apr 8, 2015 at 1:14 AM, Sean P. DeNigris >>>> <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >>>> >>>> Dale Henrichs-3 wrote >>>> > Personally I use >>>> > https://github.com/ThierryGoubier/GitFileTree-MergeDriver and >>>> never >>>> > think twice about the properties files ... >>>> >>>> Ooh, intriguing. In other to make it easier to view code on >>>> GitHub, I've >>>> been toying with the idea of generating one-class-per-file in >>>> addition to >>>> the regular gitfiletree files. Could this be used to make that >>>> possible >>>> without complicating Git? >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Metacello-GIT-methodProperties-json- >>>> tp4818097p4818233.html >>>> Sent from the Pharo Smalltalk Users mailing list archive at >>>> Nabble.com. >>>> >>>> >>>> >>> >> >> >

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Thierry Goubier

2015-04-08 9:19 GMT+02:00 Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at>: > Excerpts from Peter UhnÃ¡k's message of 2015-04-08 08:47:15 +0200: > > > I thnk that rather than focus on the disk format which I hardly ever > > > actually look at > > i think the disk format is crucial for interoperability with other tools, > such > as github webinterface, or external editors to work on things like > pictures or data. > (which is not yet supported (i have an idea how support could look like > though)) > Open subject... I think there are a few ideas floating around, and maybe a need to see a vision around that. i don't mind file-per-method though, it helps to make the diff-stat more > readable, showing which methods have been changed, added or removed... > > > ... that folks should be looking at tools support (like > > > Thierry) ... this is where the real work needs to happen ... good > tools can > > > hide the disk fomat completely so why does the disk format matter ... > > I am personally not really a fan of this; I've been using git for a while > > and I am perfectly content with using command line on the disk (maybe I'm > > rare breed); I have yet to see a GUI/tool that would come even close to > the > > power of command line, but I've been using Linux for a long time. > > except for displaying the history graph. can't beat gitk or other gui > tools for that. > having a smalltalk version of that graph would really be great! > +1 I saw Martin Dias tools for Epicea during PharoDays, and he has that visualisation in his history browser. I wanted to reuse it, but for now I'm more like chasing bugs and coping with the increased use for gitfiletree. > > > As I've > > said to Thierry some time ago in different thread, I would be interested > in > > idea of having everything on disk side and Pharo would only somehow > refresh > > it's content (just like a Java IDE / text editor would). > > can't you already do that, except that you need to manually update the > image by > loading/adopting the current state from the repo? > There is a bit more behind that. At the moment, if you reopen / refresh a repository inspector, you'll get that update. If you browse from the repository, you'll get a 'original' style browser on the stored code, but dead (can't edit). A vision would be to have normal editing over the repository -- then we could have repository state tracking (and reuse the IDE browser code instead of cloning it inside MC). But there is a conflict with smalltalk vision of live coding: you need a far deeper connection of the repository and the Pharo image, and this is clearly not how CMS are designed... git and fossil and the likes are managing dead files, which is a concept which is clearly older than the beginnings of Smalltalk, and it shows. For me, anything clearly Smalltalk-ish in that approach would require a close integration of the image and a versionning Object persistent storage (which would be smalltalk-only in access to, for example, guarantee syntax correctness). Thierry > greetings, martin. > > -- > eKita - the online platform for your entire academic > life > -- > chief engineer > eKita.co > pike programmer pike.lysator.liu.se caudium.net > societyserver.org > secretary > beijinglug.org > mentor > fossasia.org > foresight developer foresightlinux.org > realss.com > unix sysadmin > Martin BÃ¤hr working in china > http://societyserver.org/mbaehr/ > >

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Martin BÃ¤hr

Excerpts from Peter UhnÃ¡k's message of 2015-04-08 08:47:15 +0200: > > I thnk that rather than focus on the disk format which I hardly ever > > actually look at i think the disk format is crucial for interoperability with other tools, such as github webinterface, or external editors to work on things like pictures or data. (which is not yet supported (i have an idea how support could look like though)) i don't mind file-per-method though, it helps to make the diff-stat more readable, showing which methods have been changed, added or removed... > ... that folks should be looking at tools support (like > > Thierry) ... this is where the real work needs to happen ... good tools can > > hide the disk fomat completely so why does the disk format matter ... > I am personally not really a fan of this; I've been using git for a while > and I am perfectly content with using command line on the disk (maybe I'm > rare breed); I have yet to see a GUI/tool that would come even close to the > power of command line, but I've been using Linux for a long time. except for displaying the history graph. can't beat gitk or other gui tools for that. having a smalltalk version of that graph would really be great! > As I've > said to Thierry some time ago in different thread, I would be interested in > idea of having everything on disk side and Pharo would only somehow refresh > it's content (just like a Java IDE / text editor would). can't you already do that, except that you need to manually update the image by loading/adopting the current state from the repo? greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Peter UhnÃ¡k

> > I thnk that rather than focus on the disk format which I hardly ever > actually look at ... that folks should be looking at tools support (like > Thierry) ... this is where the real work needs to happen ... good tools can > hide the disk fomat completely so why does the disk format matter ... I am personally not really a fan of this; I've been using git for a while and I am perfectly content with using command line on the disk (maybe I'm rare breed); I have yet to see a GUI/tool that would come even close to the power of command line, but I've been using Linux for a long time. As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). But that may be a lot o work so I can only dream about it, as nobody has time for that (me included). But to bottom line this thread (for me at least, because I'm getting lost): 1. methodProperties.json provide compatibility for FileTree, so I don't want to get rid of it (for now) 2. the large amount of file changes is probably a bug (I'll try to be more observant about the commits in the future and hopefully some pattern will emerge.) 3. I shouldn't want to break things for now at least 4. more people are starting to work on Git 5. I need to learn about FileTree at some point if I want to contribute and experiment with (my) ideas (which won't be soon as I'm preparing for my finals) Thanks for all your answers. Peter On Wed, Apr 8, 2015 at 7:24 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 08/04/2015 02:05, Dale Henrichs a Ã©crit : > >> Peter, >> >> That looks like a bug in the FileTree writer ... wiht one method change >> there should have been only one method property file change ... >> > > Yes, I'd agree. This is surprising. > > Unless you had been loading that package via another repository / another > version / another branch before in the same image? > > MCMethodDefinition has a cache which consider equals methods with > different timestamps, and, in that case, it would carry the timestamps of > the previous version, and writing those upon save instead of the originals. > > Peter and Sean, >> >> If you are interested in contributing code/bugfixes to FileTree, I will >> welcome pull requests ... As I have mentioned in several posts today, I >> do not have the time to fiddle with changes to the FileTree format >> myself, but I welcome contributions. >> >> Damien has started work on an updated version of the FileTree format[2]. >> >> I have threatened in the past to add an option to a repository that >> would eliminate the need to store monticello meta data ... Damien is >> working on "starting from scratch" on the new format, because the >> current implementation supports 4-5 different FileTree formats. Damien's >> work could be leveraged to add an "optional Monticello meta data" option >> to FileTree and if your SCM (like git) gives you per method history with >> the proper tools you can leverage that information.. >> > > I would say this could be a reasonable possibility, in that you could have > two modes of compatibility: > > - Complete filetree compatibility for gitfiletree: the current situation, > with properties and version written to disk. > > - Partial filetree compatibility, where that metadata isn't written and > you rely on gitfiletree to recreate it to export as .mcz. > > Partial compatibility has two effects, which need to be considered. When > using github:// or bitbucket:// urls, filetree will be used and your > packages will end up having no version number (except .1?), no author, no > timestamps for methods, etc... And the second one is that, if you clone a > mcz inside the gitfiletree repository, the mcz ancestry of versions and > author timestamps on methods will be lost, which is something you may not > want. > > Thierry > > As I ranted in another post ... changing the disk format is the easy >> part ... building and maintaining tools for the 4-5 different Smalltalk >> dialects is a different matter ... >> >> Dale >> >> [1] https://github.com/dalehenrich/filetree/issues >> [2] https://github.com/dalehenrich/filetree/issues/144 >> On 04/07/2015 04:38 PM, Peter UhnÃ¡k wrote: >> >>> Yeah, I do use the MergeDriver and it saved me a lot of headache, but >>> when I see things like this >>> >>> https://github.com/dynacase/dynacase/commit/ >>> 90141d63bfdd433e51a768c2191e035b76c5da83 >>> >>> where one five lines long method generated 14 file changes with 180 >>> additions and 172 deletions... it makes the log on github and pull >>> requests incredibly messy. >>> >>> I don't want to cut branch under myself if I were to remove the >>> properties file. So my question now is: how hard would it be to >>> regenerate those files? >>> >>> Or maybe if it was moved to some metadirectory. This reminds me a bit >>> of svn which polluted the whole folder tree with .svn files everywhere. >>> >>> Peter >>> >>> >>> >>> On Wed, Apr 8, 2015 at 1:14 AM, Sean P. DeNigris >>> <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >>> >>> Dale Henrichs-3 wrote >>> > Personally I use >>> > https://github.com/ThierryGoubier/GitFileTree-MergeDriver and >>> never >>> > think twice about the properties files ... >>> >>> Ooh, intriguing. In other to make it easier to view code on >>> GitHub, I've >>> been toying with the idea of generating one-class-per-file in >>> addition to >>> the regular gitfiletree files. Could this be used to make that >>> possible >>> without complicating Git? >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/Metacello-GIT-methodProperties-json- >>> tp4818097p4818233.html >>> Sent from the Pharo Smalltalk Users mailing list archive at >>> Nabble.com. >>> >>> >>> >> > >

April 8, 2015

Re: [Pharo-users] happy easter :-)

by kilon alios

Not if you are Orthodox Christian ;) Happy Easter , great graphic. Did you do it by hand or you used a vector app like inkscape ? On Wed, Apr 8, 2015 at 2:08 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > A few days late :-) > > http://ws.stfx.eu/B8D2V8TO8BIE > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

April 8, 2015

Re: [Pharo-users] Eating your own dog food (Site/Blog)

by stepharo

I started to work on using pillar to do that but nothing ready for people to use. I will work on it at Lviv or during my vacations just after. I want to use it for my website. Right now parts of it are automatically generated from Pharo. Stef Le 7/4/15 10:56, Yuriy Tymchuk a Ã©crit : > Oh, I knew that there was a discussion about that, but couldnât find where. > > Still, is anybody else using Marina except for Pharo website? > > Uko > > > >> On 07 Apr 2015, at 10:45, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> >> >> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: >> >>> if I want to create a site/blog in pharoâ¦ What do I use? I know that >>> there is Pier, but when you check its webpage, the last update is in >>> 2011. Pharo website is built with Marina, but when I check the repo, >>> the last commit was done by me and it was 2 month ago. Will Marina >>> continue to evolve? And is anyone else using Marina? >> >> http://forum.world.st/Any-framework-to-create-a-blog-over-seaside-td4810615… >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." --Winston Churchill >> > >

April 8, 2015