July 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

On Fri, Jul 24, 2015 at 1:13 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-07-24 13:04 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> >> Alex, would you be able to show something with Roassal? It would be >>> really nice to see the overall git history graph overlaid with the graph of >>> the history of the selected package. >>> >> >> Interesting that if someone else needs it I have no problem writing >> Roassal scripts etc, but when I need it I don't even think of using Roassal >> to actually solve my problems... >> > > :) > > >> >> Anyway I ran into similar issue I had before, that >> McFileTreeGitRepository is returning GitFileTreePackageEntry instead of >> filenames, so this fails. >> > >> ~~~~~~~~~~~~~~~~ >> mc := MCFileTreeGitRepository allInstances detect: [ :m | m name >> includesSubstring: 'dynacase/repository' ]. >> >> root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc >> readableFileNames doesn't return file names" >> ~~~~~~~~~~~~~~~ >> (The above for SmalltalkHub repos works just fine.) >> > > Yes. I spent a lot of time try to guess what was the repository API used > by Monticello, and I failed for part of it ;) > > With git, I couldn't work with something as primitive as a file name to > refer to a git commit :) so had to work at a higher level and try to patch > all the places where Monticello was forcing strings on me. > Ok, so should I work around this because it's unfixable, or is it a bug? > > >> >> This is the previous issue you've already fixed >> http://forum.world.st/GitFileTree-browsing-changes-doesn-t-work-in-Pharo-5-… >> , it seems related. >> > > Ok. It is present in Pharo 4 as well, then. > I'm not sure how is Pharo 4 related (I do all dev in 5 now). > > Thanks, > > Thierry > >> >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

2015-07-24 13:04 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > Alex, would you be able to show something with Roassal? It would be really >> nice to see the overall git history graph overlaid with the graph of the >> history of the selected package. >> > > Interesting that if someone else needs it I have no problem writing > Roassal scripts etc, but when I need it I don't even think of using Roassal > to actually solve my problems... > :) > > Anyway I ran into similar issue I had before, that McFileTreeGitRepository > is returning GitFileTreePackageEntry instead of filenames, so this fails. > > ~~~~~~~~~~~~~~~~ > mc := MCFileTreeGitRepository allInstances detect: [ :m | m name > includesSubstring: 'dynacase/repository' ]. > > root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc > readableFileNames doesn't return file names" > ~~~~~~~~~~~~~~~ > (The above for SmalltalkHub repos works just fine.) > Yes. I spent a lot of time try to guess what was the repository API used by Monticello, and I failed for part of it ;) With git, I couldn't work with something as primitive as a file name to refer to a git commit :) so had to work at a higher level and try to patch all the places where Monticello was forcing strings on me. > > This is the previous issue you've already fixed > http://forum.world.st/GitFileTree-browsing-changes-doesn-t-work-in-Pharo-5-… > , it seems related. > Ok. It is present in Pharo 4 as well, then. Thanks, Thierry >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

> Alex, would you be able to show something with Roassal? It would be really > nice to see the overall git history graph overlaid with the graph of the > history of the selected package. > Interesting that if someone else needs it I have no problem writing Roassal scripts etc, but when I need it I don't even think of using Roassal to actually solve my problems... Anyway I ran into similar issue I had before, that McFileTreeGitRepository is returning GitFileTreePackageEntry instead of filenames, so this fails. ~~~~~~~~~~~~~~~~ mc := MCFileTreeGitRepository allInstances detect: [ :m | m name includesSubstring: 'dynacase/repository' ]. root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc readableFileNames doesn't return file names" ~~~~~~~~~~~~~~~ (The above for SmalltalkHub repos works just fine.) This is the previous issue you've already fixed http://forum.world.st/GitFileTree-browsing-changes-doesn-t-work-in-Pharo-5-… , it seems related. Peter

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

Hi Peter, here is my analysis on DynaCASE-PeterUhnak.147. When going through the history on git, many of the merges do not register as belonging to the DynaCASE package (a git commit belongs to a package when it modify something inside the package directory or modify the version file, I don't remember which indicator I used...). So, to be able to recover all the parents of DynaCASE-PeterUhnak.147, the algorithm (one) has to go through thoses merges transitively until all the branches it has so followed ends with a commit belonging to DynaCASE. Sometimes, drawing this as a graph in the repository inspector would help immensely... Alex, would you be able to show something with Roassal? It would be really nice to see the overall git history graph overlaid with the graph of the history of the selected package. By the way, if you want to explore some of the issues you have to tackle when reading metadata in a git repository, I suggest trying gitg on the dynacase repository... and wait :) Makes Pharo look like a speedy beast :) Thierry 2015-07-24 11:05 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >>> Sorry for the lack of support on windows. You'll have to wait for >>>> libcgit. >>> >>> >>> Is there an estimated timeline when this will be? (weeks, months, years, >>> ...?) >>> >> >> I don't know; the lib has been included in the Pharo vm for a long time, >> and I remember talks about having it for Pharo5. Stef, what is the Pharo >> consortium plans on that? >> > > CCed Stef :) ^^ > > >> >> >>> Yes, this also happens to me, but it is different. >>> Actually this is what I was expecting would happen in the issue >>> described originally... that when I check changes (and it was already >>> committed) that it would just disappear as false positive... but nope, it >>> still claimed it's new and only actual git history have shown that it was a >>> false positive. >>> >>> Anyway, it doesn't seem there will be resolution for this until it can >>> be reproduced consistently... so I'll try be more observant. :) >>> >> >> Well, it may be an issue in the way diffs are built, so it would be good >> to see it confirmed. Thanks for volunteering, by the way :) >> > > As I'm the only one experiencing this apparently, I don't have a choice > but to volunteer. :) >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

> > >> Sorry for the lack of support on windows. You'll have to wait for >>> libcgit. >> >> >> Is there an estimated timeline when this will be? (weeks, months, years, >> ...?) >> > > I don't know; the lib has been included in the Pharo vm for a long time, > and I remember talks about having it for Pharo5. Stef, what is the Pharo > consortium plans on that? > CCed Stef :) ^^ > > >> Yes, this also happens to me, but it is different. >> Actually this is what I was expecting would happen in the issue described >> originally... that when I check changes (and it was already committed) that >> it would just disappear as false positive... but nope, it still claimed >> it's new and only actual git history have shown that it was a false >> positive. >> >> Anyway, it doesn't seem there will be resolution for this until it can be >> reproduced consistently... so I'll try be more observant. :) >> > > Well, it may be an issue in the way diffs are built, so it would be good > to see it confirmed. Thanks for volunteering, by the way :) > As I'm the only one experiencing this apparently, I don't have a choice but to volunteer. :)

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

Hi Peter, 2015-07-24 10:47 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Check which versions are bold when you open the package. Because when I >> use gitfiletree it usually shows me that the latest few versions are not >> loaded (they are in bold) but I am anyway on the latest one. > > > As I've said, it shows me that I am on the latest version. > > I'm looking at DynaCASE-PeterUhnak.147, the one with the interesting history... > Maybe this happens to you because you load it from github and only after > you add gitfiletree? (At least from what I remember what you've shown me > (and you are using GitFileTree from MetaRepo30?)) > > Understood. So this means all commits you've done (the -bliznjan) were >> done with filetree? >> > > He suffered through with git on Windows for some time, so maybe the later > half? > Again, sorry for that poor Windows support... GitFileTree is an excellent bench for the robustness of the external process support, and I only barely touch the underlying plugin on Unix-like platform. I'll write for professional reasons another possibility for support on Windows, but it won't be available. > > Sorry for the lack of support on windows. You'll have to wait for >> libcgit. > > > Is there an estimated timeline when this will be? (weeks, months, years, > ...?) > I don't know; the lib has been included in the Pharo vm for a long time, and I remember talks about having it for Pharo5. Stef, what is the Pharo consortium plans on that? > Yes, this also happens to me, but it is different. > Actually this is what I was expecting would happen in the issue described > originally... that when I check changes (and it was already committed) that > it would just disappear as false positive... but nope, it still claimed > it's new and only actual git history have shown that it was a false > positive. > > Anyway, it doesn't seem there will be resolution for this until it can be > reproduced consistently... so I'll try be more observant. :) > Well, it may be an issue in the way diffs are built, so it would be good to see it confirmed. Thanks for volunteering, by the way :) Thierry

July 24, 2015

Re: [Pharo-users] Semantics of #resignalAs:

by Norbert Hartl

Joachim, thanks for looking into it. The text is the one from ANSI. I'm also puzzled about the last sentence "Control does not return from this message to the currently active exception action." I think it means after the resignalling has been done it does not return after the invocation of the #resignalAs: call. As the original signalling context is restored and only the exception is exchanged it could indeed mean that it only works if the resignalled exception does not share the same class hierarchy as the excpetion the original #on:do: catch. If the resignalled exception is the same class or a subclass of the original one it would loop. In this case I need to fix Voyage :) Norbert > Am 24.07.2015 um 08:38 schrieb jtuchel(a)objektfabrik.de: > > Hi again, > > okay, trying in VAST didn't shed much light, because resignalAs: is implemented as > > ^self error: 'Not yet implemented'. > > ;-))) > > But here is an excerpt from the method's comment: > > Synopsis: > Signal an alternative exception in place of the receiver. > > Definition: <signaledException> > The active exception action is aborted and the exception environment and the evaluation context > are restored to the same states that were in effect when the receiver was originally signaled. > > Restoring the evaluation context may result in the execution of #ensure: or #ifCurtailed: > termination blocks. > > After the restoration, signal the replacementException and execute the exception action as > determined by the restored exception environment. > > This message causes the replacementException to be treated as if it had been originally > signaled instead of the receiver. > > If the replacementException is resumable and its exception action resumes, control will > ultimately return from the message that signaled the original exception. > > Control does not return from this message to the currently active exception action. > > > If I understand correctly, the [1/0] should only be run once and never again, and you should get a NotFound error. > > ....But: > > In VisualWorks, I also get a Halt instead of a MustBeBoolean (I had to Replace NotFound with something available in VW, so I used MustBeBoolen). > > > So I am puzzled... Hoping for someone to shed some light on this... > > Joachim > > > > Am 24.07.15 um 08:25 schrieb jtuchel(a)objektfabrik.de: >> Definitely looks wrong to me... The catching block shouldn't catch exceptions in itself, and a resignal should never run the block again... >> >> I'll try this in VAST. >> >> >> Am 23.07.15 um 20:05 schrieb Norbert Hartl: >>> You get a debugger at the position if the halt in the code. Meaning the exception block run more than once. And it would run forever. >>> >>> Norbert >>> >>> >>> >>>> Am 23.07.2015 um 18:46 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: >>>> >>>> Norbert, >>>> >>>> Sorry if this is a stupid question: what does the debugger say? >>>> >>>> I mean, assuming NotFound is an Exception, I'd expect a debugger showing a NotFound Error... >>>> >>>> Joachim >>>> >>>> Am 23.07.2015 18:34 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>> >>>>>> Am 23.07.2015 um 17:54 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: >>>>>> >>>>>> Norbert, >>>>>> >>>>>> I'd say you get a NotFound Exception. >>>>> In pharo you get a debugger. Meaning this piece of code is actively an endless loop. >>>>> >>>>> Norbert >>>>> >>>>>> Joachim >>>>>> >>>>>> >>>>>> >>>>>>> Am 23.07.2015 um 16:20 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>>>> >>>>>>> What are the semantics of Exception>>#resignalAs: regarding active exception handler? Isn't the active exception handler excluded from being treated again? Taking the example >>>>>>> >>>>>>> | counter | >>>>>>> counter := 0. >>>>>>> [ 1/0 ] >>>>>>> on: Error >>>>>>> do: [ :e | >>>>>>> counter := counter + 1. >>>>>>> counter > 1 ifTrue: [ self halt ]. >>>>>>> e resignalAs: NotFound new ]. >>>>>>> >>>>>>> should it just run and end? Or should the debugger pop up? >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Norbert >>>>> >>>>> >> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

> > Check which versions are bold when you open the package. Because when I > use gitfiletree it usually shows me that the latest few versions are not > loaded (they are in bold) but I am anyway on the latest one. As I've said, it shows me that I am on the latest version. Maybe this happens to you because you load it from github and only after you add gitfiletree? (At least from what I remember what you've shown me (and you are using GitFileTree from MetaRepo30?)) Understood. So this means all commits you've done (the -bliznjan) were done > with filetree? > He suffered through with git on Windows for some time, so maybe the later half? Sorry for the lack of support on windows. You'll have to wait for libcgit. Is there an estimated timeline when this will be? (weeks, months, years, ...?) > Barely similar behavior to ghost changes is that when I finish my loading > script, DynaCASE package is marked as changed, but when I try to get diff > (changes) with (git)filetree, it says nothing has changed and this > "changed" > mark disappears. When you look at the way the changed flag is set in Monticello, it is > obvious false positives are the order of the day. So nothing really > significant there ;) Yes, this also happens to me, but it is different. Actually this is what I was expecting would happen in the issue described originally... that when I check changes (and it was already committed) that it would just disappear as false positive... but nope, it still claimed it's new and only actual git history have shown that it was a false positive. Anyway, it doesn't seem there will be resolution for this until it can be reproduced consistently... so I'll try be more observant. :) Thanks, Peter

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

2015-07-24 9:21 GMT+02:00 Jan BlizniÄenko <bliznjan(a)fit.cvut.cz>: > Yes it is. > > I personally never ran into such ghost changes when I was using > gitfiletree. > This might be also useful information: We are two contributors and Peter > uses GitFileTree but I use FileTree because GitFileTree crashes all the > time > on Win 7 ( > http://forum.world.st/Gitfiletree-unstable-on-Windows-td4816354.html ). > Understood. So this means all commits you've done (the -bliznjan) were done with filetree? Sorry for the lack of support on windows. You'll have to wait for libcgit. > > Barely similar behavior to ghost changes is that when I finish my loading > script, DynaCASE package is marked as changed, but when I try to get diff > (changes) with (git)filetree, it says nothing has changed and this > "changed" > mark disappears. > When you look at the way the changed flag is set in Monticello, it is obvious false positives are the order of the day. So nothing really significant there ;) Thierry > > Jan > > > Thierry Goubier wrote > > Peter, is this the dynacase at https://github.com/dynacase/dynacase ? > > > > Thierry > > > > > > -- > View this message in context: > http://forum.world.st/gitfiletree-metadata-tp4838970p4839019.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Jan BlizniÄenko

Yes it is. I personally never ran into such ghost changes when I was using gitfiletree. This might be also useful information: We are two contributors and Peter uses GitFileTree but I use FileTree because GitFileTree crashes all the time on Win 7 ( http://forum.world.st/Gitfiletree-unstable-on-Windows-td4816354.html ). Barely similar behavior to ghost changes is that when I finish my loading script, DynaCASE package is marked as changed, but when I try to get diff (changes) with (git)filetree, it says nothing has changed and this "changed" mark disappears. Jan Thierry Goubier wrote > Peter, is this the dynacase at https://github.com/dynacase/dynacase ? > > Thierry -- View this message in context: http://forum.world.st/gitfiletree-metadata-tp4838970p4839019.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 24, 2015

Re: [Pharo-users] Semantics of #resignalAs:

by jtuchel＠objektfabrik.de

Hi again, okay, trying in VAST didn't shed much light, because resignalAs: is implemented as ^self error: 'Not yet implemented'. ;-))) But here is an excerpt from the method's comment: Synopsis: Signal an alternative exception in place of the receiver. Definition: <signaledException> The active exception action is aborted and the exception environment and the evaluation context are restored to the same states that were in effect when the receiver was originally signaled. Restoring the evaluation context may result in the execution of #ensure: or #ifCurtailed: termination blocks. After the restoration, signal the replacementException and execute the exception action as determined by the restored exception environment. This message causes the replacementException to be treated as if it had been originally signaled instead of the receiver. If the replacementException is resumable and its exception action resumes, control will ultimately return from the message that signaled the original exception. Control does not return from this message to the currently active exception action. If I understand correctly, the [1/0] should only be run once and never again, and you should get a NotFound error. ....But: In VisualWorks, I also get a Halt instead of a MustBeBoolean (I had to Replace NotFound with something available in VW, so I used MustBeBoolen). So I am puzzled... Hoping for someone to shed some light on this... Joachim Am 24.07.15 um 08:25 schrieb jtuchel(a)objektfabrik.de: > Definitely looks wrong to me... The catching block shouldn't catch > exceptions in itself, and a resignal should never run the block again... > > I'll try this in VAST. > > > Am 23.07.15 um 20:05 schrieb Norbert Hartl: >> You get a debugger at the position if the halt in the code. Meaning >> the exception block run more than once. And it would run forever. >> >> Norbert >> >> >> >>> Am 23.07.2015 um 18:46 schrieb Joachim Tuchel >>> <jtuchel(a)objektfabrik.de>: >>> >>> Norbert, >>> >>> Sorry if this is a stupid question: what does the debugger say? >>> >>> I mean, assuming NotFound is an Exception, I'd expect a debugger >>> showing a NotFound Error... >>> >>> Joachim >>> >>> Am 23.07.2015 18:34 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>> >>>>> Am 23.07.2015 um 17:54 schrieb Joachim Tuchel >>>>> <jtuchel(a)objektfabrik.de>: >>>>> >>>>> Norbert, >>>>> >>>>> I'd say you get a NotFound Exception. >>>> In pharo you get a debugger. Meaning this piece of code is actively >>>> an endless loop. >>>> >>>> Norbert >>>> >>>>> Joachim >>>>> >>>>> >>>>> >>>>>> Am 23.07.2015 um 16:20 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>>> >>>>>> What are the semantics of Exception>>#resignalAs: regarding >>>>>> active exception handler? Isn't the active exception handler >>>>>> excluded from being treated again? Taking the example >>>>>> >>>>>> | counter | >>>>>> counter := 0. >>>>>> [ 1/0 ] >>>>>> on: Error >>>>>> do: [ :e | >>>>>> counter := counter + 1. >>>>>> counter > 1 ifTrue: [ self halt ]. >>>>>> e resignalAs: NotFound new ]. >>>>>> >>>>>> should it just run and end? Or should the debugger pop up? >>>>>> >>>>>> thanks, >>>>>> >>>>>> Norbert >>>> >>>> > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

July 24, 2015

Re: [Pharo-users] Semantics of #resignalAs:

by jtuchel＠objektfabrik.de

Definitely looks wrong to me... The catching block shouldn't catch exceptions in itself, and a resignal should never run the block again... I'll try this in VAST. Am 23.07.15 um 20:05 schrieb Norbert Hartl: > You get a debugger at the position if the halt in the code. Meaning the exception block run more than once. And it would run forever. > > Norbert > > > >> Am 23.07.2015 um 18:46 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: >> >> Norbert, >> >> Sorry if this is a stupid question: what does the debugger say? >> >> I mean, assuming NotFound is an Exception, I'd expect a debugger showing a NotFound Error... >> >> Joachim >> >> Am 23.07.2015 18:34 schrieb Norbert Hartl <norbert(a)hartl.name>: >>> >>>> Am 23.07.2015 um 17:54 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: >>>> >>>> Norbert, >>>> >>>> I'd say you get a NotFound Exception. >>> In pharo you get a debugger. Meaning this piece of code is actively an endless loop. >>> >>> Norbert >>> >>>> Joachim >>>> >>>> >>>> >>>>> Am 23.07.2015 um 16:20 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>> >>>>> What are the semantics of Exception>>#resignalAs: regarding active exception handler? Isn't the active exception handler excluded from being treated again? Taking the example >>>>> >>>>> | counter | >>>>> counter := 0. >>>>> [ 1/0 ] >>>>> on: Error >>>>> do: [ :e | >>>>> counter := counter + 1. >>>>> counter > 1 ifTrue: [ self halt ]. >>>>> e resignalAs: NotFound new ]. >>>>> >>>>> should it just run and end? Or should the debugger pop up? >>>>> >>>>> thanks, >>>>> >>>>> Norbert >>> >>> -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

Peter, is this the dynacase at https://github.com/dynacase/dynacase ? Thierry Le 24/07/2015 02:29, Peter UhnÃ¡k a Ã©crit : > > > On Fri, Jul 24, 2015 at 12:26 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Peter, > > no, I don't think you fucked up your gitfiletree metadata. But the > explanation is a bit complex. > > First thing is that you are looking at a git generated metadata... > So what you're asking for (regenerating from git) is already what > you are looking at :) > > Second is that gitfiletree walks your git log to rebuilt the version > history. So, I guess that if you look at your git with something > like gitg, you will recognize all the versions coming along the > diagram lines. > > It is linked a bit in the way gitfiletree reads through the merges > in the git history. I was surprised by that effect, I had a look and > yes, there is a good reason for having this done in that way, even > if it is a bit surprising at first. Don't remember the exact > reasoning... but it was linked to the way git links commits to > directories and how merge points appear. > > If you want to explore that part of GitFileTree, it is in > GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:. > > > Hmm, I'll look at that but still I think it shows way more than it should. > > > The ghost changes are something else, however. Can you elaborate? > > > Basically Pharo (Monticello Browser/Nautilus) shows that a package has > changes... so I look at the changes (to see what I'm committing) and I > see things that I've already committed. And if I commit it again, only > metadata will change (because it was already committed), but the dirty > flag will disappear. > > I have no idea under what circumstances this happens, I thought that > maybe I am in different commit... but monticello browser says that I am > at the latest one... > So I have yet to tell what is the cause. > > Peter

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Yuriy Tymchuk

Check which versions are bold when you open the package. Because when I use gitfiletree it usually shows me that the latest few versions are not loaded (they are in bold) but I am anyway on the latest one. Uko > On 24 Jul 2015, at 02:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > On Fri, Jul 24, 2015 at 12:26 AM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > Hi Peter, > > no, I don't think you fucked up your gitfiletree metadata. But the explanation is a bit complex. > > First thing is that you are looking at a git generated metadata... So what you're asking for (regenerating from git) is already what you are looking at :) > > Second is that gitfiletree walks your git log to rebuilt the version history. So, I guess that if you look at your git with something like gitg, you will recognize all the versions coming along the diagram lines. > > It is linked a bit in the way gitfiletree reads through the merges in the git history. I was surprised by that effect, I had a look and yes, there is a good reason for having this done in that way, even if it is a bit surprising at first. Don't remember the exact reasoning... but it was linked to the way git links commits to directories and how merge points appear. > > If you want to explore that part of GitFileTree, it is in GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:. > > Hmm, I'll look at that but still I think it shows way more than it should. > > > The ghost changes are something else, however. Can you elaborate? > > Basically Pharo (Monticello Browser/Nautilus) shows that a package has changes... so I look at the changes (to see what I'm committing) and I see things that I've already committed. And if I commit it again, only metadata will change (because it was already committed), but the dirty flag will disappear. > > I have no idea under what circumstances this happens, I thought that maybe I am in different commit... but monticello browser says that I am at the latest one... > So I have yet to tell what is the cause. > > Peter > > > > > Thierry > > > Le 23/07/2015 23:49, Peter UhnÃ¡k a Ã©crit : > Hi, > > it seems that I managed to completely fuck up my gitfiletree metadata... > > e.g.: > Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, > DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, > DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, > DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, > DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, > DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, > DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, > DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, > DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, > DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, > DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91 > > I am also starting to see a lot of ghost changes etc. > > Now, someone mentioned that it would be possible to delete all the > .version and methodProperties.json and whatnot and generate it directly > from git. > > So my question is, is this possible? If yes, how? If no, what would need > to be done (implemented) to make it so? > > Or at least is it possible to completely regenerate all the metadata > purely from git? (To clean up all the mess until.) > > Peter > > >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

On Fri, Jul 24, 2015 at 12:26 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Peter, > > no, I don't think you fucked up your gitfiletree metadata. But the > explanation is a bit complex. > > First thing is that you are looking at a git generated metadata... So what > you're asking for (regenerating from git) is already what you are looking > at :) > > Second is that gitfiletree walks your git log to rebuilt the version > history. So, I guess that if you look at your git with something like gitg, > you will recognize all the versions coming along the diagram lines. > > It is linked a bit in the way gitfiletree reads through the merges in the > git history. I was surprised by that effect, I had a look and yes, there is > a good reason for having this done in that way, even if it is a bit > surprising at first. Don't remember the exact reasoning... but it was > linked to the way git links commits to directories and how merge points > appear. > > If you want to explore that part of GitFileTree, it is in > GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:. > Hmm, I'll look at that but still I think it shows way more than it should. > > The ghost changes are something else, however. Can you elaborate? Basically Pharo (Monticello Browser/Nautilus) shows that a package has changes... so I look at the changes (to see what I'm committing) and I see things that I've already committed. And if I commit it again, only metadata will change (because it was already committed), but the dirty flag will disappear. I have no idea under what circumstances this happens, I thought that maybe I am in different commit... but monticello browser says that I am at the latest one... So I have yet to tell what is the cause. Peter > > > Thierry > > > Le 23/07/2015 23:49, Peter UhnÃ¡k a Ã©crit : > >> Hi, >> >> it seems that I managed to completely fuck up my gitfiletree metadata... >> >> e.g.: >> Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, >> DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, >> DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, >> DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, >> DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, >> DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, >> DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, >> DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, >> DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, >> DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, >> DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91 >> >> I am also starting to see a lot of ghost changes etc. >> >> Now, someone mentioned that it would be possible to delete all the >> .version and methodProperties.json and whatnot and generate it directly >> from git. >> >> So my question is, is this possible? If yes, how? If no, what would need >> to be done (implemented) to make it so? >> >> Or at least is it possible to completely regenerate all the metadata >> purely from git? (To clean up all the mess until.) >> >> Peter >> > > >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

Hi Peter, no, I don't think you fucked up your gitfiletree metadata. But the explanation is a bit complex. First thing is that you are looking at a git generated metadata... So what you're asking for (regenerating from git) is already what you are looking at :) Second is that gitfiletree walks your git log to rebuilt the version history. So, I guess that if you look at your git with something like gitg, you will recognize all the versions coming along the diagram lines. It is linked a bit in the way gitfiletree reads through the merges in the git history. I was surprised by that effect, I had a look and yes, there is a good reason for having this done in that way, even if it is a bit surprising at first. Don't remember the exact reasoning... but it was linked to the way git links commits to directories and how merge points appear. If you want to explore that part of GitFileTree, it is in GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:. The ghost changes are something else, however. Can you elaborate? Thierry Le 23/07/2015 23:49, Peter UhnÃ¡k a Ã©crit : > Hi, > > it seems that I managed to completely fuck up my gitfiletree metadata... > > e.g.: > Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, > DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, > DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, > DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, > DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, > DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, > DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, > DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, > DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, > DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, > DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91 > > I am also starting to see a lot of ghost changes etc. > > Now, someone mentioned that it would be possible to delete all the > .version and methodProperties.json and whatnot and generate it directly > from git. > > So my question is, is this possible? If yes, how? If no, what would need > to be done (implemented) to make it so? > > Or at least is it possible to completely regenerate all the metadata > purely from git? (To clean up all the mess until.) > > Peter

July 23, 2015

Re: [Pharo-users] Trying to load ViDI in Pharo 4 gives an error

by Yuriy Tymchuk

Hi, I will take a look at that, but at the moment Iâm in the airport awaiting my flight, and itâs not very comfortable to debug configurations here. Please be patient :) Cheers Uko > On 23 Jul 2015, at 22:14, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Hi - > > > When I run this: > > > Gofer new > smalltalkhubUser: 'YuriyTymchuk' > project: 'Configuration'; > configurationOf: 'Vidi'; > load. > #ConfigurationOfVidi asClass loadStable > > > I get a error that the 1.2.14 version of ConfigruationOfRubric cannot be found. The ConfigurationOfRubric is loaded from the > > MCSmalltalkhubRepository > owner: 'AlainPlantec' > project: 'Rubric' > user: '' > password: '' > > > repo. Is there another one it should be loading? > > > Thanks > > Paul

July 23, 2015

gitfiletree metadata

by Peter UhnÃ¡k

Hi, it seems that I managed to completely fuck up my gitfiletree metadata... e.g.: Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91 I am also starting to see a lot of ghost changes etc. Now, someone mentioned that it would be possible to delete all the .version and methodProperties.json and whatnot and generate it directly from git. So my question is, is this possible? If yes, how? If no, what would need to be done (implemented) to make it so? Or at least is it possible to completely regenerate all the metadata purely from git? (To clean up all the mess until.) Peter

July 23, 2015

Screamer for Smalltalk?

by Paul DeBruicker

Hi Screamer (https://nikodemus.github.io/screamer/) is a Lisp library that: "Screamer provides a nondeterministic choice-point operator, a backtracking mechanism, and a forward propagation facility." Is there an equivalent library available in Smalltalk? Thanks Paul

July 23, 2015

Trying to load ViDI in Pharo 4 gives an error

by Paul DeBruicker

Hi - When I run this: Gofer new smalltalkhubUser: 'YuriyTymchuk' project: 'Configuration'; configurationOf: 'Vidi'; load. #ConfigurationOfVidi asClass loadStable I get a error that the 1.2.14 version of ConfigruationOfRubric cannot be found. The ConfigurationOfRubric is loaded from the MCSmalltalkhubRepository owner: 'AlainPlantec' project: 'Rubric' user: '' password: '' repo. Is there another one it should be loading? Thanks Paul

July 23, 2015

Re: [Pharo-users] [OT] Bill Gross: The single biggest reason why startups succeed

by Dimitris Chloupis

for me as a beginner a big turn off was the quality of documentation and my fear that third party libraries will not be that well supported because of the size of the community meaning more bugs less features etc. It was certainly a much bigger struggle learning pharo than learning python. After 2 years Pharo has gotten much better in both areas. I can't blame people who try Pharo and are turned off by these things, but I still recommend it for at least giving it a try. In my case because I have found an easy way to combine python with pharo made it easy to move to pharo. I still love to work with Pharo and its getting better each year because of the passion of people behind this and of course their hard work. I also like to support a project that follows my taste on how I like to code , even if its not that popular. Actually its easier to feel that you make a difference in a small community. Something tells me I will be sticking around for a long long time :) I dont think there is a secret to success or a simple advice. I once read that "success" is name of the tip of an iceberg called "constant failure". [image: success.jpg] On Thu, Jul 23, 2015 at 8:25 PM stepharo <stepharo(a)free.fr> wrote: > Hi esteban > > we need to be much much better one talking to external libraries. > Our esteban is working on it. > > Stef > > Le 23/7/15 18:52, Esteban A. Maringolo a Ã©crit : > > Peter, > At your joung age you might have very good reasons to have chosen Pharo > over anything else as I did a lot of years ago. I discovered Smaltalk by > chance when I was 21 years old and already had my years developing with > Perl and was starting to learn Java. Fortunately I started making a living > out of it since I was 22 until today. > > But if you want to make the community bigger you have to look into why > people don't chose it, otherwise we'll be "preaching to the choir" as we > many times are. > > These days FP is on the bull trend, having been there way before than > Smalltalk (Lisp, Haskell, etc. and their reincarnations Clojure, Scala...). > What makes them popular most of the times is not the techology per se, but > who uses it. > > Regards! > > > Esteban A. Maringolo > > 2015-07-23 13:06 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> >> >> On Thu, Jul 23, 2015 at 4:51 PM, Esteban A. Maringolo < >> emaringolo(a)gmail.com> wrote: >> >>> When I talk to "new programmers" (20-25 years old), almost all of them >>> don't get attracted by it. >>> Why? I couldn't tell. Mainly because they can't use the few >>> tools/patterns they already learnt how to, barely, use. >>> >> >> As someone who (still) falls into this range I see several (unrelated) >> reasons why they might not like it. >> >> For me personally I encountered Pharo in University in "Conceptual >> modeling" class, where it was introduced pretty much as "Oh, by the way, >> here is this completely new environment that you've never seen nor worked >> with that we will use, but we will not tell you much about it"... so my >> first experience was quite awful. I mean... I couldn't even write the code >> in my favorite text editor and I had to use this weird browser where system >> code and my own code were mangled up. Image crashing meant I lost my work. >> Now I know I can just replay changes but I didn't know it back then (the >> focus of the class was modeling, not Pharo). Bugs (this was Pharo 2 (and 3 >> beta)) were commonplace and since I had no experience I couldn't tell >> whether it was my fault or the system's fault... it was overall very >> unpleasant. >> I later (after the course) basically foced myself to look at Pharo again >> because I didn't understand why would people bother to use it... so clearly >> there must have been some value I've missed. And I don't regret that >> decision a bit, but I had to go look for it. So statistically speaking from >> the year I did the class only two or three students (to my knowledge) kept >> their interest out of 119 (so 2-3% maybe). Other years were no different. >> Next year there will be a dedicated class for Pharo so I'm curious if >> this will change somehow. >> >> But there may be other reasons why students may not like it... (looking >> again from my experience) >> From university experience perspective, the previous year (for us, and >> from what I talked with people it's not that different also for other >> universities) was a heavy massage in C and C++ where we were implementing >> very basic concepts (hashtables, and other data structures). A year where >> your main concern was to pass a automated checking system... so mostly >> memory management and creating write-only code. Plus warped concepts of OOP >> (so to use actual student quotes: "C++ is great for explaining OOP", "You >> can do OOP in pure C", or "OOP is useless, long confusing code, full of >> getters and setters, .. and slow. Inline assembler is much faster"). So >> with such concepts it's hard to give them OOP language, because they >> already made up their mind. >> >> Yet another reason I can see might be that when you are young you are >> more inclined to follow what's cool and modern and popular and shit (or has >> the word "game" in its name). >> So if today's world revolves around connectivity, internet, JavaScript >> and whatnot, then giving them a isolated environment with non-mainstream >> technology and a dead language they've never heard of (I thought that >> Smalltalk was an obscure language that died in '80s, before I found that >> actually it's alive and doing quite well) will not be met well with >> appreciation. >> >> But no reason to stop there... there market for Smalltalk is arguably >> small, so people will prefer language that is in demand by the market >> (after all, I pay my bills with JavaScript/PHP/webstuff, and not Pharo; >> because it's much easier to find a job; with Pharo I would have to >> basically start my own business to be profitable and then I would be doing >> business and not programming). >> >> And last (but not least), finding support for it is much harder, since >> the community is smaller. So it's almost all or nothing scenario. >> >> Also some of the arguments here can be applied also for functional >> programming (which I haven't (shame on me) even engaged with, besides >> messing with Haskell in XMonad (and multi-paradigm languages that have some >> functional concepts). >> >> Finally I don't think that you should expect the same behavior from >> young people (<26) as from adults. They will have different values, views, >> and whatnot... I mean that's the point of growing up and acquiring >> experience. All you can do is offer this alternative option and provide >> support. Being mainstream or non-mainstream is akin to self-fulfilling >> prophecy. (Of course exceptions happen, JavaScript was raised to glory >> because the language happen to be in the right place (browser) at the right >> time (boom of modern web)). >> >> Hmm... and this post ended up being much chaotic and longer than I >> intended to... but whatever. >> >> Peter >> >> p.s.: I like the music analogy since I was listening to k-pop while >> working (webtech), and now I am listening to ambient music when writing >> about Pharo :p >> >> > >

July 23, 2015

Re: [Pharo-users] Semantics of #resignalAs:

by Norbert Hartl

You get a debugger at the position if the halt in the code. Meaning the exception block run more than once. And it would run forever. Norbert > Am 23.07.2015 um 18:46 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: > > Norbert, > > Sorry if this is a stupid question: what does the debugger say? > > I mean, assuming NotFound is an Exception, I'd expect a debugger showing a NotFound Error... > > Joachim > > Am 23.07.2015 18:34 schrieb Norbert Hartl <norbert(a)hartl.name>: >> >> >>> Am 23.07.2015 um 17:54 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: >>> >>> Norbert, >>> >>> I'd say you get a NotFound Exception. >> In pharo you get a debugger. Meaning this piece of code is actively an endless loop. >> >> Norbert >> >>> Joachim >>> >>> >>> >>>> Am 23.07.2015 um 16:20 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>> >>>> What are the semantics of Exception>>#resignalAs: regarding active exception handler? Isn't the active exception handler excluded from being treated again? Taking the example >>>> >>>> | counter | >>>> counter := 0. >>>> [ 1/0 ] >>>> on: Error >>>> do: [ :e | >>>> counter := counter + 1. >>>> counter > 1 ifTrue: [ self halt ]. >>>> e resignalAs: NotFound new ]. >>>> >>>> should it just run and end? Or should the debugger pop up? >>>> >>>> thanks, >>>> >>>> Norbert >> >> >>

July 23, 2015

Re: [Pharo-users] [OT] Bill Gross: The single biggest reason why startups succeed

by stepharo

Hi esteban we need to be much much better one talking to external libraries. Our esteban is working on it. Stef Le 23/7/15 18:52, Esteban A. Maringolo a Ã©crit : > Peter, > At your joung age you might have very good reasons to have chosen > Pharo over anything else as I did a lot of years ago. I discovered > Smaltalk by chance when I was 21 years old and already had my years > developing with Perl and was starting to learn Java. Fortunately I > started making a living out of it since I was 22 until today. > > But if you want to make the community bigger you have to look into why > people don't chose it, otherwise we'll be "preaching to the choir" as > we many times are. > > These days FP is on the bull trend, having been there way before than > Smalltalk (Lisp, Haskell, etc. and their reincarnations Clojure, > Scala...). What makes them popular most of the times is not the > techology per se, but who uses it. > > Regards! > > > Esteban A. Maringolo > > 2015-07-23 13:06 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>>: > > > > On Thu, Jul 23, 2015 at 4:51 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > > When I talk to "new programmers" (20-25 years old), almost all > of them don't get attracted by it. > Why? I couldn't tell. Mainly because they can't use the few > tools/patterns they already learnt how to, barely, use. > > > As someone who (still) falls into this range I see several > (unrelated) reasons why they might not like it. > > For me personally I encountered Pharo in University in "Conceptual > modeling" class, where it was introduced pretty much as "Oh, by > the way, here is this completely new environment that you've never > seen nor worked with that we will use, but we will not tell you > much about it"... so my first experience was quite awful. I > mean... I couldn't even write the code in my favorite text editor > and I had to use this weird browser where system code and my own > code were mangled up. Image crashing meant I lost my work. Now I > know I can just replay changes but I didn't know it back then (the > focus of the class was modeling, not Pharo). Bugs (this was Pharo > 2 (and 3 beta)) were commonplace and since I had no experience I > couldn't tell whether it was my fault or the system's fault... it > was overall very unpleasant. > I later (after the course) basically foced myself to look at Pharo > again because I didn't understand why would people bother to use > it... so clearly there must have been some value I've missed. And > I don't regret that decision a bit, but I had to go look for it. > So statistically speaking from the year I did the class only two > or three students (to my knowledge) kept their interest out of 119 > (so 2-3% maybe). Other years were no different. > Next year there will be a dedicated class for Pharo so I'm curious > if this will change somehow. > > But there may be other reasons why students may not like it... > (looking again from my experience) > From university experience perspective, the previous year (for us, > and from what I talked with people it's not that different also > for other universities) was a heavy massage in C and C++ where we > were implementing very basic concepts (hashtables, and other data > structures). A year where your main concern was to pass a > automated checking system... so mostly memory management and > creating write-only code. Plus warped concepts of OOP (so to use > actual student quotes: "C++ is great for explaining OOP", "You can > do OOP in pure C", or "OOP is useless, long confusing code, full > of getters and setters, .. and slow. Inline assembler is much > faster"). So with such concepts it's hard to give them OOP > language, because they already made up their mind. > > Yet another reason I can see might be that when you are young you > are more inclined to follow what's cool and modern and popular and > shit (or has the word "game" in its name). > So if today's world revolves around connectivity, internet, > JavaScript and whatnot, then giving them a isolated environment > with non-mainstream technology and a dead language they've never > heard of (I thought that Smalltalk was an obscure language that > died in '80s, before I found that actually it's alive and doing > quite well) will not be met well with appreciation. > > But no reason to stop there... there market for Smalltalk is > arguably small, so people will prefer language that is in demand > by the market (after all, I pay my bills with > JavaScript/PHP/webstuff, and not Pharo; because it's much easier > to find a job; with Pharo I would have to basically start my own > business to be profitable and then I would be doing business and > not programming). > > And last (but not least), finding support for it is much harder, > since the community is smaller. So it's almost all or nothing > scenario. > > Also some of the arguments here can be applied also for functional > programming (which I haven't (shame on me) even engaged with, > besides messing with Haskell in XMonad (and multi-paradigm > languages that have some functional concepts). > > Finally I don't think that you should expect the same behavior > from young people (<26) as from adults. They will have different > values, views, and whatnot... I mean that's the point of growing > up and acquiring experience. All you can do is offer this > alternative option and provide support. Being mainstream or > non-mainstream is akin to self-fulfilling prophecy. (Of course > exceptions happen, JavaScript was raised to glory because the > language happen to be in the right place (browser) at the right > time (boom of modern web)). > > Hmm... and this post ended up being much chaotic and longer than I > intended to... but whatever. > > Peter > > p.s.: I like the music analogy since I was listening to k-pop > while working (webtech), and now I am listening to ambient music > when writing about Pharo :p > >

July 23, 2015

Re: [Pharo-users] [OT] Bill Gross: The single biggest reason why startups succeed

by stepharo

> totally. it is exactly the feeling i have about smalltalk and lisp. > i learned both because i wanted to know if the newer languages everyone is > using are really any better. i'd expected that they would learn and improve > over older languages. but i had to discover that that's not the case. > > i used to believe that languages like python, ruby and pike were a new > generation of languages that improved over the old languages like c and c++, > but i was disappointed and had to find out that the innovation already happened > a few decades earlier and almost everything else following was a step backwards > in some ways. :) This is why we should continue to rethink our tools, frameworks, process

July 23, 2015

Re: [Pharo-users] [OT] Bill Gross: The single biggest reason why startups succeed

by Esteban A. Maringolo

Peter, At your joung age you might have very good reasons to have chosen Pharo over anything else as I did a lot of years ago. I discovered Smaltalk by chance when I was 21 years old and already had my years developing with Perl and was starting to learn Java. Fortunately I started making a living out of it since I was 22 until today. But if you want to make the community bigger you have to look into why people don't chose it, otherwise we'll be "preaching to the choir" as we many times are. These days FP is on the bull trend, having been there way before than Smalltalk (Lisp, Haskell, etc. and their reincarnations Clojure, Scala...). What makes them popular most of the times is not the techology per se, but who uses it. Regards! Esteban A. Maringolo 2015-07-23 13:06 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > > On Thu, Jul 23, 2015 at 4:51 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> When I talk to "new programmers" (20-25 years old), almost all of them >> don't get attracted by it. >> Why? I couldn't tell. Mainly because they can't use the few >> tools/patterns they already learnt how to, barely, use. >> > > As someone who (still) falls into this range I see several (unrelated) > reasons why they might not like it. > > For me personally I encountered Pharo in University in "Conceptual > modeling" class, where it was introduced pretty much as "Oh, by the way, > here is this completely new environment that you've never seen nor worked > with that we will use, but we will not tell you much about it"... so my > first experience was quite awful. I mean... I couldn't even write the code > in my favorite text editor and I had to use this weird browser where system > code and my own code were mangled up. Image crashing meant I lost my work. > Now I know I can just replay changes but I didn't know it back then (the > focus of the class was modeling, not Pharo). Bugs (this was Pharo 2 (and 3 > beta)) were commonplace and since I had no experience I couldn't tell > whether it was my fault or the system's fault... it was overall very > unpleasant. > I later (after the course) basically foced myself to look at Pharo again > because I didn't understand why would people bother to use it... so clearly > there must have been some value I've missed. And I don't regret that > decision a bit, but I had to go look for it. So statistically speaking from > the year I did the class only two or three students (to my knowledge) kept > their interest out of 119 (so 2-3% maybe). Other years were no different. > Next year there will be a dedicated class for Pharo so I'm curious if this > will change somehow. > > But there may be other reasons why students may not like it... (looking > again from my experience) > From university experience perspective, the previous year (for us, and > from what I talked with people it's not that different also for other > universities) was a heavy massage in C and C++ where we were implementing > very basic concepts (hashtables, and other data structures). A year where > your main concern was to pass a automated checking system... so mostly > memory management and creating write-only code. Plus warped concepts of OOP > (so to use actual student quotes: "C++ is great for explaining OOP", "You > can do OOP in pure C", or "OOP is useless, long confusing code, full of > getters and setters, .. and slow. Inline assembler is much faster"). So > with such concepts it's hard to give them OOP language, because they > already made up their mind. > > Yet another reason I can see might be that when you are young you are more > inclined to follow what's cool and modern and popular and shit (or has the > word "game" in its name). > So if today's world revolves around connectivity, internet, JavaScript and > whatnot, then giving them a isolated environment with non-mainstream > technology and a dead language they've never heard of (I thought that > Smalltalk was an obscure language that died in '80s, before I found that > actually it's alive and doing quite well) will not be met well with > appreciation. > > But no reason to stop there... there market for Smalltalk is arguably > small, so people will prefer language that is in demand by the market > (after all, I pay my bills with JavaScript/PHP/webstuff, and not Pharo; > because it's much easier to find a job; with Pharo I would have to > basically start my own business to be profitable and then I would be doing > business and not programming). > > And last (but not least), finding support for it is much harder, since the > community is smaller. So it's almost all or nothing scenario. > > Also some of the arguments here can be applied also for functional > programming (which I haven't (shame on me) even engaged with, besides > messing with Haskell in XMonad (and multi-paradigm languages that have some > functional concepts). > > Finally I don't think that you should expect the same behavior from young > people (<26) as from adults. They will have different values, views, and > whatnot... I mean that's the point of growing up and acquiring experience. > All you can do is offer this alternative option and provide support. Being > mainstream or non-mainstream is akin to self-fulfilling prophecy. (Of > course exceptions happen, JavaScript was raised to glory because the > language happen to be in the right place (browser) at the right time (boom > of modern web)). > > Hmm... and this post ended up being much chaotic and longer than I > intended to... but whatever. > > Peter > > p.s.: I like the music analogy since I was listening to k-pop while > working (webtech), and now I am listening to ambient music when writing > about Pharo :p > >

July 23, 2015