- Pharo-dev - lists.pharo.org

Re: [Pharo-project] StandardFonts defautFont:

by Alain Plantec

Le 21/02/2011 18:53, Hilaire Fernandes a Ã©crit : > I am struggling with this method where it looks like default font is > locked to 9 pt size, not a piece of cake for XO laptop. > > Hilaire --------------- | f n | n := StandardFonts defaultFont. "get the current default font" f := LogicalFontfamilyName: n familyName pointSize: 12. "font for my preferred size" StandardFonts setAllStandardFontsTo: f "reset all fonts" --------------- Cheers Alain > > >

Feb. 22, 2011

Re: [Pharo-project] SqueakSource down... again

by Philippe Marschall

On 02/21/2011 05:39 PM, Adrian Lienhard wrote: > > On Feb 21, 2011, at 17:22 , Camillo Bruni wrote: > >> how about a file based system and git? > > yea, just discussed this very idea an hour ago... > > The simplest thing that could work: > - Write out changes to files (for each method and class) > - Use git to commit, push, pull, merge, etc. > - After git actions, load changed files and compile Been there, done that. Was called DVS, the predecessor of Monticello. It sucked. Cheers Philippe

Feb. 22, 2011

Re: [Pharo-project] SqueakSource down... again

by Max Leske

Camillo, actually Lukas did something with Monticello and my GitFS package called "MonticelloGit". There's only one version so far and I haven't looked at it but if anyone's interested, you can find the package on SqueakSouce: http://www.squeaksource.com/GitFS.html Max On 21.02.2011, at 23:35, Camillo Bruni wrote: > On 2011-02-21, at 22:52, Alexandre Bergel wrote: > >>> Max Leske, a student in bern started to write a git library for smalltalk. so there should be already quite some stuff available. >>> but AFAIK there is no MC adapter yet. >> >> I do not have much experience with Git, but do you think it is feasible to have such adapter? >> >> Alexandre > > Actually I have no clue of the MC internals ;), so I will have to go deep there. At least there has been an approach using svn: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/13143… > > Although I have no clue how much this is still in use, or if it even works. But combined with the git communication libraries available it should be possible to patch them together. > > I would like to see that happen, not just for me, but also to see more smalltalk sources on the web. The current google hit-ratio is a nightmare :D. And maybe it even helps to share some code with GNU smalltalkses or so. > > m(^_-)m > camillo > >>> personally I would really appreciate that (also for other versioning tools). >>> >>> - I like to choose my own tools >>> - I don't like to stick in a image-based world, but I certainly want to stay compatible >>> - I want quality!! and sending fileouts via mail is NOT >>> >>> And it seems that this is a discussion which pops up from time to time, hence I would really appreciate this getting to work at some point in the near future. >>> >>> Some links I will further follow tomorrow to address this issue: >>> >>> - gitfs: http://buildinggitfs.blogspot.com/ >>> http://www.squeaksource.com/@KNo72_87ZPtfmMDX/OIzsRG2C >>> - gitocello: https://github.com/timfel/gitocello >>> - http://gsoc2010.esug.org/projects/pharo/squeak%20integration%20with%20git/m… >>> - git for squeak: http://www.squeaksource.com/@8Fz2hHOzNG-JG7LQ/kHiMji1K >>> >>> >>> m(^_-)m >>> camillo >>> >>> On 2011-02-21, at 19:28, Steven Baker wrote: >>> >>>> FWIW, Git is a very generic system. There's no reason we couldn't >>>> write a storage adapter for MC that puts the repo in Git. Git only >>>> knows about objects, and the versions thereof. We could easily have >>>> Monticello on top of git. >>>> >>>> I'm not sure I think it's a good solution, but it sounds like >>>> something fun to hack on, if someone wants to join me. (I'm not doing >>>> a project I only peripherally care about all by my lonesome.) >>>> >>>> -Steven >>>> >>>> On Mon, Feb 21, 2011 at 10:25 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>> Hi Esteban, >>>>> >>>>> I look forward to testing it :) >>>>> >>>>> BTW, SqueakSource is not the problem for me (we have a HTTP repository). The MC speed is what bothers us most... I just responded in this thread since the idea was mentioned by Camillo. I know that other people are more attached to the "Smalltalk way" of doing things and prefer staying with MC, but I think we should seriously consider alternatives (as you apparently already do). I believe that closing the gap between the file-based languages and Smalltalk is possible without giving up too much... >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> On Feb 21, 2011, at 18:52 , Esteban Lorenzano wrote: >>>>> >>>>>> Hi, >>>>>> I'm already working in a file based solution... it will be ready for test next one or two months :) >>>>>> >>>>>> There are some advantages I want to point: >>>>>> - Better for newcomers >>>>>> - Better for customers who "want to see the sources" (yes, I have some of them, time to time) >>>>>> - We don't need to take care about infrastructure anymore, just use one already existing (like Github) >>>>>> - Increases Pharo visibility in the web (this is really important, IMHO) >>>>>> - "Hybrid" projects (with external files) like VM, for instance, and many Seaside projects, can have just one source point (so tags, etc. has no need to be manually matched with monticello repository). >>>>>> - the solution I'm building (not just me, this is with a friend of mine who does not participate in the list) can work together with monticello, so you can have your sources "frozen" in the disk (and commit to git), and create a monticello version if you need it :) >>>>>> - We will use coral source format to keep files in disk, so they will be more readable than current file-out format (well, this can take a little more than two months, because I'm still understanding it) >>>>>> >>>>>> On the disadvantages... >>>>>> - Most important (because of the "smalltalk culture", mostly) is the fact we loose the "all in smalltalk" thing...but that's not an issue IMHO. Pharo community is a lot more open than others, and we already are using some non-smalltalk tools (like hudson for building and google for tracking) >>>>>> - Yes, merging, etc. can be harder, but I think using a nice file format can lower this impact (and we are still supporting image-to/from-file merging). >>>>>> >>>>>> A couple of years ago some guys released SqueakSVN, as an alternative, but it failed to become an option... I think because SVN was already old at that time, and also because installation, etc. was hard, and also because it was an "incomplete" work, I think. Anyway... I'm doing this stuff because I need it, and I hope some others will consider it useful :) >>>>>> So... well... stay in touch ;) >>>>>> >>>>>> cheers, >>>>>> Esteban >>>>>> >>>>>> pd: yes... I know... I'm currently handling more projects than I can do... and that delays all my projects... but I'm doing my best, and any help is welcome :) >>>>>> >>>>>> El 21/02/2011, a las 1:55p.m., Guillermo Polito escribiÃ³: >>>>>> >>>>>>> I don't know if we have to change to another kind of service. But we MUST have alternatives. >>>>>>> >>>>>>> On Mon, Feb 21, 2011 at 1:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>>> Come on. We are talking about quality of service here, or about >>>>>>> changing the service? >>>>>>> I don't think that after migrating to (put your favorite here), we >>>>>>> won't have any new problems. And then same, lack of people who can >>>>>>> address them. >>>>>>> >>>>>>> On 21 February 2011 17:39, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>>>> >>>>>>>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote: >>>>>>>> >>>>>>>>> how about a file based system and git? >>>>>>>> >>>>>>>> yea, just discussed this very idea an hour ago... >>>>>>>> >>>>>>>> The simplest thing that could work: >>>>>>>> - Write out changes to files (for each method and class) >>>>>>>> - Use git to commit, push, pull, merge, etc. >>>>>>>> - After git actions, load changed files and compile >>>>>>>> >>>>>>>> Advantage: >>>>>>>> - can reuse good existing tools and infrastructure: git, github, etc. >>>>>>>> - probably faster than MC + SqueakSource >>>>>>>> - lower entry barrier for new people >>>>>>>> >>>>>>>> Disadvantage: >>>>>>>> - source control tools not integrated anymore >>>>>>>> - resolving merge conflicts may be tedious >>>>>>>> - we don't have our own solution for everything anymore ;) >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>>> >>>>>>>>> On 2011-02-21, at 16:48, Fabrizio Perin wrote: >>>>>>>>> >>>>>>>>>> Well more or less every 10 days i need to restart it. This discussion happen >>>>>>>>>> already in different threads but again the problems are: >>>>>>>>>> 1- The machine hosting squeaksource is an old mac. Maybe on a new machine >>>>>>>>>> running linux it could be better. >>>>>>>>>> 2- SqueakSource is running in a squeakimage on a SqueakVM 3.9 (if i'm not >>>>>>>>>> wrong - anyway is very old stuff) and as far as i get, a porting to a more >>>>>>>>>> recent environment (let say a pharo 1.3 on a cog vm) will mean to rewrite >>>>>>>>>> entirely squaeksource. >>>>>>>>>> >>>>>>>>>> Now, this is a well know problem and a lot of people is already moving to >>>>>>>>>> solve it (surely you can find lots of email from Stephan talking about >>>>>>>>>> this). I'm trying to keep the system alive. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Fabrizio >>>>>>>>>> >>>>>>>>>> 2011/2/21 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> do nothing, just wait and see until SqueakSource turns completely unusable. >>>>>>>>>>> >>>>>>>>>>> I don't know if people won't noticed or don't want to admit it, but >>>>>>>>>>> SqueakSource is down very often lately.. >>>>>>>>>>> >>>>>>>>>>> 2011/2/21 Fabrizio Perin <fabrizio.perin(a)gmail.com>: >>>>>>>>>>>> SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i >>>>>>>>>>> don't >>>>>>>>>>>> know how i can help you. >>>>>>>>>>>> >>>>>>>>>>>> 2011/2/21 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> SqueakSource is down again. I'm tired of this situation, there is any >>>>>>>>>>>>> alternative "free" repository? >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> HernÃ¡n Morales >>>>>>>>>>>>> Information Technology Manager, >>>>>>>>>>>>> Institute of Veterinary Genetics. >>>>>>>>>>>>> National Scientific and Technical Research Council (CONICET). >>>>>>>>>>>>> La Plata (1900), Buenos Aires, Argentina. >>>>>>>>>>>>> Telephone: +54 (0221) 421-1799. >>>>>>>>>>>>> Internal: 422 >>>>>>>>>>>>> Fax: 425-7980 or 421-1799. >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > >

Feb. 22, 2011

[Pharo-project] what is the name of the menu that comes up when you use action-click?

by Sheridan Mahoney

Is it simply called the action-click menu? -- View this message in context: http://forum.world.st/what-is-the-name-of-the-menu-that-comes-up-when-you-u… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 22, 2011

[Pharo-project] Non-functional RFBServer with Squeak 4.2 all-in-one.

by Lawson English

Has anyone managed to get RFBServer working with the 4.2 final release? Someone on #squeak irc had mouse issues with it, and when I installed the latest version, I found that mouse events were not being passed back to squeak at all from my VNC client. This is obviously a show-stopper, but I don't know how to fix it. Has anyone tested the Pharo RFBServer version with 4.2? THanks. Lawson

Feb. 22, 2011

[Pharo-project] Pharo Sources Google Hit Ratio

by Camillo Bruni

I just figured you cannot use google to program in pharo!! At least my common approach is to use google to search for some code snippets in order to fill my overloaded brain. How about setting up a website, Browse Pharo, which has a simple UI for browsing the majority of the Pharo sources. Unlike squeaksource, it should be properly indexed by google, e.g. feature NICE and DESCRIPTIVE URLs. I do not know the exact circumstances of squeaksource's amazing low google index, but I think we can change this. m(^_-)m camillo

Feb. 21, 2011

Re: [Pharo-project] SqueakSource down... again

by Camillo Bruni

On 2011-02-21, at 22:52, Alexandre Bergel wrote: >> Max Leske, a student in bern started to write a git library for smalltalk. so there should be already quite some stuff available. >> but AFAIK there is no MC adapter yet. > > I do not have much experience with Git, but do you think it is feasible to have such adapter? > > Alexandre Actually I have no clue of the MC internals ;), so I will have to go deep there. At least there has been an approach using svn: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/13143… Although I have no clue how much this is still in use, or if it even works. But combined with the git communication libraries available it should be possible to patch them together. I would like to see that happen, not just for me, but also to see more smalltalk sources on the web. The current google hit-ratio is a nightmare :D. And maybe it even helps to share some code with GNU smalltalkses or so. m(^_-)m camillo >> personally I would really appreciate that (also for other versioning tools). >> >> - I like to choose my own tools >> - I don't like to stick in a image-based world, but I certainly want to stay compatible >> - I want quality!! and sending fileouts via mail is NOT >> >> And it seems that this is a discussion which pops up from time to time, hence I would really appreciate this getting to work at some point in the near future. >> >> Some links I will further follow tomorrow to address this issue: >> >> - gitfs: http://buildinggitfs.blogspot.com/ >> http://www.squeaksource.com/@KNo72_87ZPtfmMDX/OIzsRG2C >> - gitocello: https://github.com/timfel/gitocello >> - http://gsoc2010.esug.org/projects/pharo/squeak%20integration%20with%20git/m… >> - git for squeak: http://www.squeaksource.com/@8Fz2hHOzNG-JG7LQ/kHiMji1K >> >> >> m(^_-)m >> camillo >> >> On 2011-02-21, at 19:28, Steven Baker wrote: >> >>> FWIW, Git is a very generic system. There's no reason we couldn't >>> write a storage adapter for MC that puts the repo in Git. Git only >>> knows about objects, and the versions thereof. We could easily have >>> Monticello on top of git. >>> >>> I'm not sure I think it's a good solution, but it sounds like >>> something fun to hack on, if someone wants to join me. (I'm not doing >>> a project I only peripherally care about all by my lonesome.) >>> >>> -Steven >>> >>> On Mon, Feb 21, 2011 at 10:25 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>> Hi Esteban, >>>> >>>> I look forward to testing it :) >>>> >>>> BTW, SqueakSource is not the problem for me (we have a HTTP repository). The MC speed is what bothers us most... I just responded in this thread since the idea was mentioned by Camillo. I know that other people are more attached to the "Smalltalk way" of doing things and prefer staying with MC, but I think we should seriously consider alternatives (as you apparently already do). I believe that closing the gap between the file-based languages and Smalltalk is possible without giving up too much... >>>> >>>> Cheers, >>>> Adrian >>>> >>>> On Feb 21, 2011, at 18:52 , Esteban Lorenzano wrote: >>>> >>>>> Hi, >>>>> I'm already working in a file based solution... it will be ready for test next one or two months :) >>>>> >>>>> There are some advantages I want to point: >>>>> - Better for newcomers >>>>> - Better for customers who "want to see the sources" (yes, I have some of them, time to time) >>>>> - We don't need to take care about infrastructure anymore, just use one already existing (like Github) >>>>> - Increases Pharo visibility in the web (this is really important, IMHO) >>>>> - "Hybrid" projects (with external files) like VM, for instance, and many Seaside projects, can have just one source point (so tags, etc. has no need to be manually matched with monticello repository). >>>>> - the solution I'm building (not just me, this is with a friend of mine who does not participate in the list) can work together with monticello, so you can have your sources "frozen" in the disk (and commit to git), and create a monticello version if you need it :) >>>>> - We will use coral source format to keep files in disk, so they will be more readable than current file-out format (well, this can take a little more than two months, because I'm still understanding it) >>>>> >>>>> On the disadvantages... >>>>> - Most important (because of the "smalltalk culture", mostly) is the fact we loose the "all in smalltalk" thing...but that's not an issue IMHO. Pharo community is a lot more open than others, and we already are using some non-smalltalk tools (like hudson for building and google for tracking) >>>>> - Yes, merging, etc. can be harder, but I think using a nice file format can lower this impact (and we are still supporting image-to/from-file merging). >>>>> >>>>> A couple of years ago some guys released SqueakSVN, as an alternative, but it failed to become an option... I think because SVN was already old at that time, and also because installation, etc. was hard, and also because it was an "incomplete" work, I think. Anyway... I'm doing this stuff because I need it, and I hope some others will consider it useful :) >>>>> So... well... stay in touch ;) >>>>> >>>>> cheers, >>>>> Esteban >>>>> >>>>> pd: yes... I know... I'm currently handling more projects than I can do... and that delays all my projects... but I'm doing my best, and any help is welcome :) >>>>> >>>>> El 21/02/2011, a las 1:55p.m., Guillermo Polito escribiÃ³: >>>>> >>>>>> I don't know if we have to change to another kind of service. But we MUST have alternatives. >>>>>> >>>>>> On Mon, Feb 21, 2011 at 1:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>> Come on. We are talking about quality of service here, or about >>>>>> changing the service? >>>>>> I don't think that after migrating to (put your favorite here), we >>>>>> won't have any new problems. And then same, lack of people who can >>>>>> address them. >>>>>> >>>>>> On 21 February 2011 17:39, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>>> >>>>>>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote: >>>>>>> >>>>>>>> how about a file based system and git? >>>>>>> >>>>>>> yea, just discussed this very idea an hour ago... >>>>>>> >>>>>>> The simplest thing that could work: >>>>>>> - Write out changes to files (for each method and class) >>>>>>> - Use git to commit, push, pull, merge, etc. >>>>>>> - After git actions, load changed files and compile >>>>>>> >>>>>>> Advantage: >>>>>>> - can reuse good existing tools and infrastructure: git, github, etc. >>>>>>> - probably faster than MC + SqueakSource >>>>>>> - lower entry barrier for new people >>>>>>> >>>>>>> Disadvantage: >>>>>>> - source control tools not integrated anymore >>>>>>> - resolving merge conflicts may be tedious >>>>>>> - we don't have our own solution for everything anymore ;) >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>>> >>>>>>>> On 2011-02-21, at 16:48, Fabrizio Perin wrote: >>>>>>>> >>>>>>>>> Well more or less every 10 days i need to restart it. This discussion happen >>>>>>>>> already in different threads but again the problems are: >>>>>>>>> 1- The machine hosting squeaksource is an old mac. Maybe on a new machine >>>>>>>>> running linux it could be better. >>>>>>>>> 2- SqueakSource is running in a squeakimage on a SqueakVM 3.9 (if i'm not >>>>>>>>> wrong - anyway is very old stuff) and as far as i get, a porting to a more >>>>>>>>> recent environment (let say a pharo 1.3 on a cog vm) will mean to rewrite >>>>>>>>> entirely squaeksource. >>>>>>>>> >>>>>>>>> Now, this is a well know problem and a lot of people is already moving to >>>>>>>>> solve it (surely you can find lots of email from Stephan talking about >>>>>>>>> this). I'm trying to keep the system alive. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Fabrizio >>>>>>>>> >>>>>>>>> 2011/2/21 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> do nothing, just wait and see until SqueakSource turns completely unusable. >>>>>>>>>> >>>>>>>>>> I don't know if people won't noticed or don't want to admit it, but >>>>>>>>>> SqueakSource is down very often lately.. >>>>>>>>>> >>>>>>>>>> 2011/2/21 Fabrizio Perin <fabrizio.perin(a)gmail.com>: >>>>>>>>>>> SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i >>>>>>>>>> don't >>>>>>>>>>> know how i can help you. >>>>>>>>>>> >>>>>>>>>>> 2011/2/21 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >>>>>>>>>>>> >>>>>>>>>>>> SqueakSource is down again. I'm tired of this situation, there is any >>>>>>>>>>>> alternative "free" repository? >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> HernÃ¡n Morales >>>>>>>>>>>> Information Technology Manager, >>>>>>>>>>>> Institute of Veterinary Genetics. >>>>>>>>>>>> National Scientific and Technical Research Council (CONICET). >>>>>>>>>>>> La Plata (1900), Buenos Aires, Argentina. >>>>>>>>>>>> Telephone: +54 (0221) 421-1799. >>>>>>>>>>>> Internal: 422 >>>>>>>>>>>> Fax: 425-7980 or 421-1799. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Feb. 21, 2011

Re: [Pharo-project] SqueakSource down... again

by Alexandre Bergel

> Max Leske, a student in bern started to write a git library for smalltalk. so there should be already quite some stuff available. > but AFAIK there is no MC adapter yet. I do not have much experience with Git, but do you think it is feasible to have such adapter? Alexandre > > personally I would really appreciate that (also for other versioning tools). > > - I like to choose my own tools > - I don't like to stick in a image-based world, but I certainly want to stay compatible > - I want quality!! and sending fileouts via mail is NOT > > And it seems that this is a discussion which pops up from time to time, hence I would really appreciate this getting to work at some point in the near future. > > Some links I will further follow tomorrow to address this issue: > > - gitfs: http://buildinggitfs.blogspot.com/ > http://www.squeaksource.com/@KNo72_87ZPtfmMDX/OIzsRG2C > - gitocello: https://github.com/timfel/gitocello > - http://gsoc2010.esug.org/projects/pharo/squeak%20integration%20with%20git/m… > - git for squeak: http://www.squeaksource.com/@8Fz2hHOzNG-JG7LQ/kHiMji1K > > > m(^_-)m > camillo > > On 2011-02-21, at 19:28, Steven Baker wrote: > >> FWIW, Git is a very generic system. There's no reason we couldn't >> write a storage adapter for MC that puts the repo in Git. Git only >> knows about objects, and the versions thereof. We could easily have >> Monticello on top of git. >> >> I'm not sure I think it's a good solution, but it sounds like >> something fun to hack on, if someone wants to join me. (I'm not doing >> a project I only peripherally care about all by my lonesome.) >> >> -Steven >> >> On Mon, Feb 21, 2011 at 10:25 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> Hi Esteban, >>> >>> I look forward to testing it :) >>> >>> BTW, SqueakSource is not the problem for me (we have a HTTP repository). The MC speed is what bothers us most... I just responded in this thread since the idea was mentioned by Camillo. I know that other people are more attached to the "Smalltalk way" of doing things and prefer staying with MC, but I think we should seriously consider alternatives (as you apparently already do). I believe that closing the gap between the file-based languages and Smalltalk is possible without giving up too much... >>> >>> Cheers, >>> Adrian >>> >>> On Feb 21, 2011, at 18:52 , Esteban Lorenzano wrote: >>> >>>> Hi, >>>> I'm already working in a file based solution... it will be ready for test next one or two months :) >>>> >>>> There are some advantages I want to point: >>>> - Better for newcomers >>>> - Better for customers who "want to see the sources" (yes, I have some of them, time to time) >>>> - We don't need to take care about infrastructure anymore, just use one already existing (like Github) >>>> - Increases Pharo visibility in the web (this is really important, IMHO) >>>> - "Hybrid" projects (with external files) like VM, for instance, and many Seaside projects, can have just one source point (so tags, etc. has no need to be manually matched with monticello repository). >>>> - the solution I'm building (not just me, this is with a friend of mine who does not participate in the list) can work together with monticello, so you can have your sources "frozen" in the disk (and commit to git), and create a monticello version if you need it :) >>>> - We will use coral source format to keep files in disk, so they will be more readable than current file-out format (well, this can take a little more than two months, because I'm still understanding it) >>>> >>>> On the disadvantages... >>>> - Most important (because of the "smalltalk culture", mostly) is the fact we loose the "all in smalltalk" thing...but that's not an issue IMHO. Pharo community is a lot more open than others, and we already are using some non-smalltalk tools (like hudson for building and google for tracking) >>>> - Yes, merging, etc. can be harder, but I think using a nice file format can lower this impact (and we are still supporting image-to/from-file merging). >>>> >>>> A couple of years ago some guys released SqueakSVN, as an alternative, but it failed to become an option... I think because SVN was already old at that time, and also because installation, etc. was hard, and also because it was an "incomplete" work, I think. Anyway... I'm doing this stuff because I need it, and I hope some others will consider it useful :) >>>> So... well... stay in touch ;) >>>> >>>> cheers, >>>> Esteban >>>> >>>> pd: yes... I know... I'm currently handling more projects than I can do... and that delays all my projects... but I'm doing my best, and any help is welcome :) >>>> >>>> El 21/02/2011, a las 1:55p.m., Guillermo Polito escribiÃ³: >>>> >>>>> I don't know if we have to change to another kind of service. But we MUST have alternatives. >>>>> >>>>> On Mon, Feb 21, 2011 at 1:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> Come on. We are talking about quality of service here, or about >>>>> changing the service? >>>>> I don't think that after migrating to (put your favorite here), we >>>>> won't have any new problems. And then same, lack of people who can >>>>> address them. >>>>> >>>>> On 21 February 2011 17:39, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>> >>>>>> On Feb 21, 2011, at 17:22 , Camillo Bruni wrote: >>>>>> >>>>>>> how about a file based system and git? >>>>>> >>>>>> yea, just discussed this very idea an hour ago... >>>>>> >>>>>> The simplest thing that could work: >>>>>> - Write out changes to files (for each method and class) >>>>>> - Use git to commit, push, pull, merge, etc. >>>>>> - After git actions, load changed files and compile >>>>>> >>>>>> Advantage: >>>>>> - can reuse good existing tools and infrastructure: git, github, etc. >>>>>> - probably faster than MC + SqueakSource >>>>>> - lower entry barrier for new people >>>>>> >>>>>> Disadvantage: >>>>>> - source control tools not integrated anymore >>>>>> - resolving merge conflicts may be tedious >>>>>> - we don't have our own solution for everything anymore ;) >>>>>> >>>>>> Adrian >>>>>> >>>>>>> >>>>>>> On 2011-02-21, at 16:48, Fabrizio Perin wrote: >>>>>>> >>>>>>>> Well more or less every 10 days i need to restart it. This discussion happen >>>>>>>> already in different threads but again the problems are: >>>>>>>> 1- The machine hosting squeaksource is an old mac. Maybe on a new machine >>>>>>>> running linux it could be better. >>>>>>>> 2- SqueakSource is running in a squeakimage on a SqueakVM 3.9 (if i'm not >>>>>>>> wrong - anyway is very old stuff) and as far as i get, a porting to a more >>>>>>>> recent environment (let say a pharo 1.3 on a cog vm) will mean to rewrite >>>>>>>> entirely squaeksource. >>>>>>>> >>>>>>>> Now, this is a well know problem and a lot of people is already moving to >>>>>>>> solve it (surely you can find lots of email from Stephan talking about >>>>>>>> this). I'm trying to keep the system alive. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Fabrizio >>>>>>>> >>>>>>>> 2011/2/21 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> do nothing, just wait and see until SqueakSource turns completely unusable. >>>>>>>>> >>>>>>>>> I don't know if people won't noticed or don't want to admit it, but >>>>>>>>> SqueakSource is down very often lately.. >>>>>>>>> >>>>>>>>> 2011/2/21 Fabrizio Perin <fabrizio.perin(a)gmail.com>: >>>>>>>>>> SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i >>>>>>>>> don't >>>>>>>>>> know how i can help you. >>>>>>>>>> >>>>>>>>>> 2011/2/21 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >>>>>>>>>>> >>>>>>>>>>> SqueakSource is down again. I'm tired of this situation, there is any >>>>>>>>>>> alternative "free" repository? >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> HernÃ¡n Morales >>>>>>>>>>> Information Technology Manager, >>>>>>>>>>> Institute of Veterinary Genetics. >>>>>>>>>>> National Scientific and Technical Research Council (CONICET). >>>>>>>>>>> La Plata (1900), Buenos Aires, Argentina. >>>>>>>>>>> Telephone: +54 (0221) 421-1799. >>>>>>>>>>> Internal: 422 >>>>>>>>>>> Fax: 425-7980 or 421-1799. >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> >>>> >>> >>> >>> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 21, 2011

Re: [Pharo-project] COG and locale

by Sven Van Caekenberghe

On 21 Feb 2011, at 21:44, Hilaire Fernandes wrote: > Le 21/02/2011 21:36, Hilaire Fernandes a Ã©crit : >> >> >> Are there any known issues with Locale with COG? > > Tracking down to the primitive calls in the class Locale, those always > return empty string. Primitive are for now unknown land for me. > > Hilaire Might be related to http://code.google.com/p/pharo/issues/detail?id=3264 ?

Feb. 21, 2011

Re: [Pharo-project] Cobol is the new language to know?

by csrabak＠bol.com.br

Em 21/02/2011 18:05, Casimiro de Almeida Barreto < casimiro.barreto(a)gmail.com > escreveu: > Em 21-02-2011 16:07, csrabak(a)bol.com.br escreveu: > > Geert, > > I'll use my consultant's hat to contribute on this. My company > > lives from selling advice on these matters. > > Notice that in the table of the referred link: > > http://www.theaustralian.com.au/australian-it/legacy-languages-prove-lucrac… > > which you point to, Cobol and Smalltalk share the same status of > > "Retire Now". > > So the Channel Register interpretation of the reports has not been > > that sharp at all. Also, the company issuing the report is an > > Aussie centered firm, as the problems we're facing in the > > companies around the world (in the mainframe) is more what to do > > with the Natural/Adabas platform, where Natural is a higher level > > language than Cobol but has a high impedance for conversion to > > Java (w/o opening the can of worms of running Java in mainframes). > > The FUD about Smalltalk going to become unsupported must be > > counteracted by the pertinent Organizations, like ESUG in Europe > > and STIC, and of course the Software companies themselves like VW > > and Instantiations. When I worked at Gartner, they had a similar > > table which included Smalltalk in the doom-way in "five years" > > ca. Y2K and recently they changed their mind a little bit: > > http://blogs.gartner.com/mark_driver/2008/10/09/remember-smalltalk/ > > and > > http://news.squeak.org/2008/10/11/smalltalk-is-cool-again-says-gartner/ > > (just a sample, Google is your friend if you're really > > interested). > > OTOH, notice that another Research company whose business is > > selling 'insight' says something about the primadonna du jour: > > http://www.cincomsmalltalk.com/main/2010/12/java-is-a-dead-end-for-enterpri… > > HTH > > > > -- Cesar Rabak > > > > Thing about these tales of "dying languages" & stuff like that is > that it's really hard to avoid conflicting interests while judging > things. > > I remember the golden age of Microsoft and its happy marriage with > Intel, when companies (Gartner included) hammered execs minds with > the TOC mantra (Microsoft as opposed to Unix/Linux - OSX not I think you mean "TCO" here ;-) > available at that time & Apple starving of Jobs). Following that > line of reasoning, by now Oracle would be history, Linux would be > history and Apple would be the only thing preventing Microsoft > running into anti-trust laws. Obviously history unrolled different > ways... >From a point of view of corporate IT, Apple _is_ history and Linux is only present in appliances. No tsunami happened in the server industry that shakes Microsoft dominance... In fact, Linux was the great bogeyman for Unix flavours. Yes it unrolled different in the details, but quite much as advertised :-) > > I don't see smalltalk "retiring" or "going six palms down" because > from the corporate vantage point smalltalk just didn't happen > (yet). Well, it happened at its time, but didn't got enough momentum to become the COBOL of OO languages. > IMO, some things prevented smalltalk going main stream: > > (a) bad marketing from smalltalk players I think we can agree on this. > (b) Java happened and its shortcomings weren't evident to community from > the start but Sun put a real bunch of money in it. Also, the moment in history and the way as the language was deployed (no competing flavours or dialects, etc.) was different than when Smalltalk was introduced. Java was mainly a means to program in OO, while Smalltalk had to convince people of way different paradigm, and learn a language. > (c) Microsoft had its own ideas about development platforms (C#, .net, etc) Of course! They make a living selling proprietary stuff! Eons ago, they got rid of their COBOL business, they Fortran business, etc. They attempted to 'embrace and extend' Java and when it backfired they got rid of "VisualJ" and went .Net... > (d) Nobody presented a (really) suitable solution to large scale > problems (performance, scalability, security, stability, etc), so > corporations kept relying on "traditional" solutions (like C, C++, > etc). Yep, in the nineties all the Smalltalk projects that I had crossed were of the nature more or less: "...we've this solution developed in Smalltalk and need to port to C++ in order to solve the __ problem, where the blank is one of the above plus some other created by management. > (e) "Mainframe world" is a completely different breed. Yup. > What's happening is that "software development world" is getting > short of solutions to jump to next Fermi levels of systems > development. Just a little look in industry and it becomes really > visible. Some development cycles in "software consumer products" are > exceeding five years & costs are surpassing hundreds of millions of > US$. Yes. > IMO smalltalk and/or its derivatives may fill important niches. But > wether this happens or not will depend on several things. The most > important of all is the availability of a clean open solution, > coherent, supported and fully documented. Currently there are two > divergent families of "open smalltalk": > > (a) gnu smalltalk > (b) squeak/pharo/cuis > > Focusing in the squeak/pharo/cuis branch, I've noticed that pharo > people got really concerned in aspects that can attract market > interest. They're looking for funding, fighting to have "hired > people" (meaning under wages) minding "hairy aspects" of > development, maintenance, documentation and some sort of > "standardization", etc. Collaborators also produced interesting > "printed material" (books, tutorials) but IMO such material is still > very academic in nature. People in industry likes best "manual" > stuff (like "foundation classes" with "methods" (messages in the > case) documented, etc). IMO (again) here lies a relevant problem: > there are "no foundation classes" (no "landmarks" or things that > cannot be easily changed) and it becomes apparent when people > exchange ideas about "keeping this" and "getting rid of that". At > least debate is going on and many issues have been addressed. > Yes. > One thing I don't (yet) like in pharo is that there's no easy way of > applying fixes. Would be nice to have an update mechanism automating > (at least) fixes installation. I think this kind of thing is > important to market acceptance of smalltalk. > ? -- Cesar Rabak

Feb. 21, 2011