August 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] What is proper fix for this?

by Esteban Lorenzano

> On 17 Aug 2017, at 11:28, jtuchel(a)objektfabrik.de wrote: > > Herby, > > back when Alan was maintaining Glorp, he took care for portability, he even maintained the port to VA Smalltalk, IIRC. Niall and Tim(?) at Cincom also try not to break any dialect in their changes and they also work on keeping things portable. I am not sure there ever was any (semi-)automated process to keep ports in sync, my guess would be that that is not the case. > > What I am very sure of is that the ppl at Cincom would welcome any volunteers to support them in keeping things portable and improve the ecosystem for this. > Is any of you going to be at ESUG? I will, but I will not maintain Glorp portâ¦ I have just too much work :) Esteban > > > Joachim > > > > > Am 17.08.17 um 10:53 schrieb Herby VojÄÃk: >> Esteban Lorenzano wrote: >>> >>>> On 17 Aug 2017, at 10:35, Guillermo Polito <guillermopolito(a)gmail.com >>>> <mailto:guillermopolito@gmail.com>> wrote: >>>> >>>> Just a thought out of thin air: wasn't filetree supposed to provide >>>> common ground for this kind of scenarios? If we shared a single >>>> repository in github that would save us a lot of discussion :P >>> >>> it doesnât :) >>> while exporting VM-Glorp to github will simplify a lot the process, >>> truth is dialects are so different they cannot talk each other in >>> general, and changes needs to be applied (by hand). >> >> I know it sounds like pipe dream, but I had the impression non-dialect-specific parts of Glorp (that is, most of it) is (was?) deliberately written in subset of Smalltalk (not ifNotNil: but isNil ifFalse: etc.) that it aimed to actually _be_ portable. >> >> That part at least (and the high-level part with descriptors, mappings, queries, glorpexpressions etc. is such) would be nice to actually be generic enough to be "any Smalltalk out there". >> >> Herby >> >>> butâ¦ having a github mirror to be able to diff properly is a good thing. >>> >>> Esteban >>> >> >> >> > > > -- > ----------------------------------------------------------------------- > 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 > >

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by jtuchel＠objektfabrik.de

Herby, back when Alan was maintaining Glorp, he took care for portability, he even maintained the port to VA Smalltalk, IIRC. Niall and Tim(?) at Cincom also try not to break any dialect in their changes and they also work on keeping things portable. I am not sure there ever was any (semi-)automated process to keep ports in sync, my guess would be that that is not the case. What I am very sure of is that the ppl at Cincom would welcome any volunteers to support them in keeping things portable and improve the ecosystem for this. Is any of you going to be at ESUG? Joachim Am 17.08.17 um 10:53 schrieb Herby VojÄÃk: > Esteban Lorenzano wrote: >> >>> On 17 Aug 2017, at 10:35, Guillermo Polito <guillermopolito(a)gmail.com >>> <mailto:guillermopolito@gmail.com>> wrote: >>> >>> Just a thought out of thin air: wasn't filetree supposed to provide >>> common ground for this kind of scenarios? If we shared a single >>> repository in github that would save us a lot of discussion :P >> >> it doesnât :) >> while exporting VM-Glorp to github will simplify a lot the process, >> truth is dialects are so different they cannot talk each other in >> general, and changes needs to be applied (by hand). > > I know it sounds like pipe dream, but I had the impression > non-dialect-specific parts of Glorp (that is, most of it) is (was?) > deliberately written in subset of Smalltalk (not ifNotNil: but isNil > ifFalse: etc.) that it aimed to actually _be_ portable. > > That part at least (and the high-level part with descriptors, > mappings, queries, glorpexpressions etc. is such) would be nice to > actually be generic enough to be "any Smalltalk out there". > > Herby > >> butâ¦ having a github mirror to be able to diff properly is a good thing. >> >> Esteban >> > > > -- ----------------------------------------------------------------------- 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

Aug. 17, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by Denis Kudriashov

Hi. I think your problem related to the old FFI syntax. In Pharo UFFI is the way to do external calls. To enable old FFI syntax try to switch compiler: Smalltalk compilerClass: Compiler I used this trick to port some small library which was based on old FFI. I made migration manually but maybe there are tools to convert old FFI methods to new one. 2017-08-16 23:31 GMT+02:00 bdurin <bruno.durin(a)gmail.com>: > Hi, > > I stumbled upon what seems to me a strange issue in Pharo 5. The RBParser > fails to correctly parse the legacy FFI pragmas. This completely breaks > down > the browser, the inspector and debugger (because as far as I understand all > use RBParser to correctly highlight syntax). I had the image crashed and > some red boxes at some point while insisting to inspect and debug. Overall > this is not a big issue but it raises some more general bells to me. > > In order to reproduce this: > - load the official Pharo 5 (curl get.pharo.org/50+vm | bash) > - launch the image (./pharo-ui Pharo.image &) > - add the following repository > MCSmalltalkhubRepository > owner: 'panuw' > project: 'zeromq' > user: '' > password: '' > - load the last versions of ZeroMQ and ConfigurationOfZeroMQ (not sure if > the latter is needed) > - open a Nautilus Browser and look at the class method apiZmqBind:to: of > the > ZmqApi class in the ZeroMQ package: you get a MessageNotUnderstood error > (receiver of keywords is nil). You can get past this by clicking on > "Abandon" but the source code is displayed in a corrupted way: > apiZmqBind: s > ocket to: endpoint <cdecl > - repeat a few times by looking at other methods until you get a red box: > then you cannot look at source code any more with this browser. If you are > obstinate and "lucky" you will succeed in crashing the image. > - you can pin the problem by running in a Playground > RBParser parseFaultyMethod: 'apiZmqBind: socket to: endpoint > <cdecl: long ''zmq_bind'' (ZmqApiSocket* char*) module:''zmq''> > ^self externalCallFailed'. > and you'll see that the pragmas is not correctly parsed. (The root cause is > that the legacy adapter RBFFICallPragma does not follow the API defined by > its super class RBPragmaNode (selector, arguments, positions) and so is not > a properly defined node. I corrected the problem by computing and setting > the corresponding instance variables.) > > 1) As a beginner at Pharo, I find it difficult to deal with the various > versions of Pharo. ZeroMQ is the (only) Smalltalk-Pharo binding for zmq. It > dates back to Feb 2014 so I expected it to work in Pharo as of 3 years and > a > half later (Pharo 6 dates back to June 2017). > I naively tried to load the package in a Pharo 6 image and it failed > because > of a syntax error. As I had read a lot about the various FFI mechanisms, I > quickly understood that it must be because the FFI declarations in pragma > are not supported anymore. > I then loaded the package in a Pharo 5 image and I got the error that I > described. After finding the error and solving it, I guess that the FFI > declaration in pragma was barely supported in Pharo 5, which has already > switched to UFFI and that it is something dating back to Pharo 4. (I did > not > try with Pharo 4 as I do not want to work with versions before 5). > Is there a way to know for a package what the compatible Pharo version is? > It seems that currently I have to look at dates, look at the features used > by the package and look for the history of development (fortunately the > mailing lists are easy to search) to understand which version is likely to > work. > Are not deprecations a bit too fast if a package written 3 years ago cannot > work in the latest Pharo version and trigger bugs in Pharo 5, which dates > back to May 2016 (so only a bit more than 2 years after)? > I find it a bit too fast as compared to mainstream languages. To my mind, > either deprecations should be slower or a version/dependencies system > should > be there to help users. > > 2) Another question about versions: Pharo 6 is out since June, Pharo 7 is > under development. What is the status of Pharo 5? Already history or still > relevant? > I am asking because I corrected the problem of FFI declaration in pragma, > but it seems to me that it is not useful to publish this change as starting > from Pharo 6 this way to do FFI is not supported. So should I contribute? > If > yes, how to "attach" the patch to Pharo 5? > > 3) As explained above, in Pharo 5, looking at the source trigger an error. > Even if this looks like a rare corner case, I think that the developer > tools > should not trigger bugs when looking at source code, even less trigger a > red > box in the source code viewer (in the browser, but the problem also occurs > --less strongly-- when looking at the object in an inspector: there should > not be "error printing" when it is only a syntax highlight problem). If the > code is malformed and the parser used to highlight syntax fails, there > should be a fallback such as the source code being displayed without any > highlight. It sends a very bad impression to have this kind of bugs when > one > simply wants to look at code, not even running it. > I have not dug enough in this area of Pharo, but it seems to me that the > parser that is used to build the AST for code execution / method > compilation > should not be the same as the parser used to highligh syntax. (Of course I > am not saying that there should be 2 distincts code base for the 2 parsers, > but they should at least run differently.) The first one must be strict > with > errors as a malformed AST cannot be executed. The second one must be > lenient, as a malformed AST does not prevent to print the string of the > source code. Of course, at the end if the code is malformed there will be > an > error at execution, but if the source code can be displayed even when it is > malformed, at least I have the opportunity to correct it so that it runs > correctly. (In this case, convert the old FFI pragma declaration into a > fficall:) > I may be missing something here but if this works the same in the most > up-to-date version of Pharo, the same kind of error might appear again. > What do you think? > > 4) A final remark: let us classify people as Beginner/Confirmed in > programming and B/C in Pharo (A BB is a beginner in programming and in > Pharo, a CC confirmed in both, a BC cannot exists and CB are those who > discover Pharo while knowing well other languages). Pharo seems to be great > for BB and CC. I went through the MOOC and the various books which are > great. My first steps in Pharo environment were great. > As a CC it seems to be great also as in the very small area of the system > where I took the time to drill into all the details, I could very easily > change things (and correct a bug), that would have been very difficult to > understand and change in a lot of other languages. Even hacking the VM > seems > to be possible for a non-VM expert. > But I consider myself rather as a CB. As such I tend to try and do complex > things that I usually do in other languages and run into tricky problems. > These problems are rather dealt with and corrected by Pharo developers but > that as a user I would expect them to remain hidden to me or to be clearly > advertised in the docs. As compared to a BB, a CB is not going to stay in a > well delimited area where everything is smooth. > True, in a way it is a very strong incentive to become a Pharo expert! But > I > am wondering if this aspect could be improved. > > Thanks, > Bruno > > > > -- > View this message in context: http://forum.world.st/Parser- > failure-on-FFI-pragmas-declaration-in-Pharo-5-tp4961737.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by Guillermo Polito

but! we could have github.pharo.org that redirects to the pharo organization in github :P On Thu, Aug 17, 2017 at 10:53 AM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Esteban Lorenzano wrote: > >> >> On 17 Aug 2017, at 10:35, Guillermo Polito <guillermopolito(a)gmail.com >>> <mailto:guillermopolito@gmail.com>> wrote: >>> >>> Just a thought out of thin air: wasn't filetree supposed to provide >>> common ground for this kind of scenarios? If we shared a single >>> repository in github that would save us a lot of discussion :P >>> >> >> it doesnât :) >> while exporting VM-Glorp to github will simplify a lot the process, >> truth is dialects are so different they cannot talk each other in >> general, and changes needs to be applied (by hand). >> > > I know it sounds like pipe dream, but I had the impression > non-dialect-specific parts of Glorp (that is, most of it) is (was?) > deliberately written in subset of Smalltalk (not ifNotNil: but isNil > ifFalse: etc.) that it aimed to actually _be_ portable. > > That part at least (and the high-level part with descriptors, mappings, > queries, glorpexpressions etc. is such) would be nice to actually be > generic enough to be "any Smalltalk out there". > > Herby > > butâ¦ having a github mirror to be able to diff properly is a good thing. >> >> Esteban >> >> > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by Herby VojÄÃk

Esteban Lorenzano wrote: > >> On 17 Aug 2017, at 10:35, Guillermo Polito <guillermopolito(a)gmail.com >> <mailto:guillermopolito@gmail.com>> wrote: >> >> Just a thought out of thin air: wasn't filetree supposed to provide >> common ground for this kind of scenarios? If we shared a single >> repository in github that would save us a lot of discussion :P > > it doesnât :) > while exporting VM-Glorp to github will simplify a lot the process, > truth is dialects are so different they cannot talk each other in > general, and changes needs to be applied (by hand). I know it sounds like pipe dream, but I had the impression non-dialect-specific parts of Glorp (that is, most of it) is (was?) deliberately written in subset of Smalltalk (not ifNotNil: but isNil ifFalse: etc.) that it aimed to actually _be_ portable. That part at least (and the high-level part with descriptors, mappings, queries, glorpexpressions etc. is such) would be nice to actually be generic enough to be "any Smalltalk out there". Herby > butâ¦ having a github mirror to be able to diff properly is a good thing. > > Esteban >

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by Esteban Lorenzano

> On 17 Aug 2017, at 10:49, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Guillermo Polito wrote: >> >> >> On Thu, Aug 17, 2017 at 10:32 AM, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> >> > On 17 Aug 2017, at 10:18, Herby VojÄÃk <herby(a)mailbox.sk >> <mailto:herby@mailbox.sk>> wrote: >> > >> > jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de> wrote: >> > > Herby, >> > > >> > > my ccomments were not meant to say you are not competent enough >> to fix >> > > Glorp. I know you have been active as the maintainer of Amber for >> quite >> > > a while now and know you are an experienced Smalltalker. So this >> is not >> > >> > Not really. Actually, never did any production-ready project in >> Smalltalk. The one I do now is the first time. >> > >> > > an attempt to make you look incompetent or "unqualified". >> > > >> > > I just wanted to point out that >> > > >> > > * I think that if there is a bug in Glorp, it should be communicated >> > > to the maintainers in order to make sure the fix is making it into >> > > newer Glorp versions and from there to all dialects that have >> a port >> > >> > Yeah, sure. But Esteban's mail suggested that it is a long >> process, so maybe it _is_ beneficial to try to shortcut the fix at >> Pharo side. >> > >> > Don't know the local politics, so can't say myself. >> >> Is not about politics :) >> basically: cincom does not maintains other platforms than themselves >> (and *I am not* complaining, this is a fair choice, we do the same >> with pharo related things). So if we want to keep the port updated >> is this community who has to do it. >> Now, in the case of Glorp this is not easy to do and last year we >> (the consortium) spent money to get an updated port. Now, if there >> is a bug and is *we* who found it, I would like to have a fix for >> our port (and of course inform it to cincom guys). >> >> In factâ¦ complexity is so big in this project that every port of >> Glorp from VW to Pharo is a âde factoâ fork (not desired, but >> necessary). And any new port/update of the port will require >> important efforts we cannot do at the moment (I guess we could diff >> versions and update just the changes we findâ¦ just to simplify. But >> still, this is a lot of work :P). >> >> Anyway, this is why if we have the opportunity to fix a bug in our >> platform, I would apply it regardless the cincom process (and our >> own update process). >> >> >> Just a thought out of thin air: wasn't filetree supposed to provide >> common ground for this kind of scenarios? If we shared a single >> repository in github that would save us a lot of discussion :P > > I'd prefer on-premise git.smalltalkhub.com, but it's just me. :-( yeah, that will not happen, sorry. we are moving to github *also* because of marketing and visibility. Esteban > > OTOH, it can be interesting if the system it runs on is decently extensible so Smalltalk-specific plugins be added (edit in place via run in squeakjs, deep-linking-like integration when open in internal browser inside pharo image, ...). > >> cheers, >> Esteban >> >> > >> >> of Glorp (Smalltalk is too much of a niche to be able to >> stand more >> >> and more niche-ification of forks and stuff, esp. for such a >> central >> >> part as Glorp which are way too important to only be >> maintained by >> >> one or two developers - which they unfortunately are, at >> least to my >> >> knowledge) >> > >> > :-( >> > >> >> * I am not sure if anybody from Cincom is listening here >> looking for >> >> Glorp problems, so I saw/see the danger of "private" fixes / >> forks >> >> * I fixed a few bugs in Glorp in the past just to find out that the >> >> concept was correct but the place to fix it was wrong (or at >> least >> >> would not heal all related problems). Glorp is complex and it has >> >> lots of layers. It is a good example of the "avoid >> responsibility" >> >> concept that was once (what a coincidence) formulated by Alan >> Knight >> >> in an article named "All I've learned about object orientation I >> >> learnt from Dilbert" (or similar) - so I was gad Niall looked >> into >> > >> > Yeah, the classic (that is, for me; lots of ppl out there do not >> know it, though they should). >> > >> >> these and gave me feedback as well as a "full" fix >> > >> > Yeah, that would be nice. >> > >> >> So I mainly ask you to post your fix and problem description to the >> >> Glorp Mailing list / Google group. It would be a pity if your fix is >> > >> > I posted (that is, I tried to; I hope it got there). >> > >> > Maybe I should reply there with a few more words... or find out >> if it got there in the first place. >> > >> > >> >> buried in some fork of Glorp. >> >> >> >> Joachim >> > >> > Herby >> > >> >> >> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - _http://www.cnrs.fr_ >> >> >> >> *Web:* _http://guillep.github.io_ >> >> *Phone: *+33 06 52 70 66 13 >> > >

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by Herby VojÄÃk

Guillermo Polito wrote: > > > On Thu, Aug 17, 2017 at 10:32 AM, Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > > > > On 17 Aug 2017, at 10:18, Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>> wrote: > > > > jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de> wrote: > > > Herby, > > > > > > my ccomments were not meant to say you are not competent enough > to fix > > > Glorp. I know you have been active as the maintainer of Amber for > quite > > > a while now and know you are an experienced Smalltalker. So this > is not > > > > Not really. Actually, never did any production-ready project in > Smalltalk. The one I do now is the first time. > > > > > an attempt to make you look incompetent or "unqualified". > > > > > > I just wanted to point out that > > > > > > * I think that if there is a bug in Glorp, it should be communicated > > > to the maintainers in order to make sure the fix is making it into > > > newer Glorp versions and from there to all dialects that have > a port > > > > Yeah, sure. But Esteban's mail suggested that it is a long > process, so maybe it _is_ beneficial to try to shortcut the fix at > Pharo side. > > > > Don't know the local politics, so can't say myself. > > Is not about politics :) > basically: cincom does not maintains other platforms than themselves > (and *I am not* complaining, this is a fair choice, we do the same > with pharo related things). So if we want to keep the port updated > is this community who has to do it. > Now, in the case of Glorp this is not easy to do and last year we > (the consortium) spent money to get an updated port. Now, if there > is a bug and is *we* who found it, I would like to have a fix for > our port (and of course inform it to cincom guys). > > In factâ¦ complexity is so big in this project that every port of > Glorp from VW to Pharo is a âde factoâ fork (not desired, but > necessary). And any new port/update of the port will require > important efforts we cannot do at the moment (I guess we could diff > versions and update just the changes we findâ¦ just to simplify. But > still, this is a lot of work :P). > > Anyway, this is why if we have the opportunity to fix a bug in our > platform, I would apply it regardless the cincom process (and our > own update process). > > > Just a thought out of thin air: wasn't filetree supposed to provide > common ground for this kind of scenarios? If we shared a single > repository in github that would save us a lot of discussion :P I'd prefer on-premise git.smalltalkhub.com, but it's just me. :-( OTOH, it can be interesting if the system it runs on is decently extensible so Smalltalk-specific plugins be added (edit in place via run in squeakjs, deep-linking-like integration when open in internal browser inside pharo image, ...). > cheers, > Esteban > > > > >> of Glorp (Smalltalk is too much of a niche to be able to > stand more > >> and more niche-ification of forks and stuff, esp. for such a > central > >> part as Glorp which are way too important to only be > maintained by > >> one or two developers - which they unfortunately are, at > least to my > >> knowledge) > > > > :-( > > > >> * I am not sure if anybody from Cincom is listening here > looking for > >> Glorp problems, so I saw/see the danger of "private" fixes / > forks > >> * I fixed a few bugs in Glorp in the past just to find out that the > >> concept was correct but the place to fix it was wrong (or at > least > >> would not heal all related problems). Glorp is complex and it has > >> lots of layers. It is a good example of the "avoid > responsibility" > >> concept that was once (what a coincidence) formulated by Alan > Knight > >> in an article named "All I've learned about object orientation I > >> learnt from Dilbert" (or similar) - so I was gad Niall looked > into > > > > Yeah, the classic (that is, for me; lots of ppl out there do not > know it, though they should). > > > >> these and gave me feedback as well as a "full" fix > > > > Yeah, that would be nice. > > > >> So I mainly ask you to post your fix and problem description to the > >> Glorp Mailing list / Google group. It would be a pity if your fix is > > > > I posted (that is, I tried to; I hope it got there). > > > > Maybe I should reply there with a few more words... or find out > if it got there in the first place. > > > > > >> buried in some fork of Glorp. > >> > >> Joachim > > > > Herby > > > > > > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - _http://www.cnrs.fr_ > > > > *Web:* _http://guillep.github.io_ > > *Phone: *+33 06 52 70 66 13 >

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by Esteban Lorenzano

> On 17 Aug 2017, at 10:35, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Just a thought out of thin air: wasn't filetree supposed to provide common ground for this kind of scenarios? If we shared a single repository in github that would save us a lot of discussion :P it doesnât :) while exporting VM-Glorp to github will simplify a lot the process, truth is dialects are so different they cannot talk each other in general, and changes needs to be applied (by hand). butâ¦ having a github mirror to be able to diff properly is a good thing. Esteban

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by Guillermo Polito

On Thu, Aug 17, 2017 at 10:32 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 17 Aug 2017, at 10:18, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > > > jtuchel(a)objektfabrik.de wrote: > >> Herby, > >> > >> my ccomments were not meant to say you are not competent enough to fix > >> Glorp. I know you have been active as the maintainer of Amber for quite > >> a while now and know you are an experienced Smalltalker. So this is not > > > > Not really. Actually, never did any production-ready project in > Smalltalk. The one I do now is the first time. > > > >> an attempt to make you look incompetent or "unqualified". > >> > >> I just wanted to point out that > >> > >> * I think that if there is a bug in Glorp, it should be communicated > >> to the maintainers in order to make sure the fix is making it into > >> newer Glorp versions and from there to all dialects that have a port > > > > Yeah, sure. But Esteban's mail suggested that it is a long process, so > maybe it _is_ beneficial to try to shortcut the fix at Pharo side. > > > > Don't know the local politics, so can't say myself. > > Is not about politics :) > basically: cincom does not maintains other platforms than themselves (and > *I am not* complaining, this is a fair choice, we do the same with pharo > related things). So if we want to keep the port updated is this community > who has to do it. > Now, in the case of Glorp this is not easy to do and last year we (the > consortium) spent money to get an updated port. Now, if there is a bug and > is *we* who found it, I would like to have a fix for our port (and of > course inform it to cincom guys). > > In factâ¦ complexity is so big in this project that every port of Glorp > from VW to Pharo is a âde factoâ fork (not desired, but necessary). And any > new port/update of the port will require important efforts we cannot do at > the moment (I guess we could diff versions and update just the changes we > findâ¦ just to simplify. But still, this is a lot of work :P). > > Anyway, this is why if we have the opportunity to fix a bug in our > platform, I would apply it regardless the cincom process (and our own > update process). > Just a thought out of thin air: wasn't filetree supposed to provide common ground for this kind of scenarios? If we shared a single repository in github that would save us a lot of discussion :P > > cheers, > Esteban > > > > >> of Glorp (Smalltalk is too much of a niche to be able to stand more > >> and more niche-ification of forks and stuff, esp. for such a central > >> part as Glorp which are way too important to only be maintained by > >> one or two developers - which they unfortunately are, at least to my > >> knowledge) > > > > :-( > > > >> * I am not sure if anybody from Cincom is listening here looking for > >> Glorp problems, so I saw/see the danger of "private" fixes / forks > >> * I fixed a few bugs in Glorp in the past just to find out that the > >> concept was correct but the place to fix it was wrong (or at least > >> would not heal all related problems). Glorp is complex and it has > >> lots of layers. It is a good example of the "avoid responsibility" > >> concept that was once (what a coincidence) formulated by Alan Knight > >> in an article named "All I've learned about object orientation I > >> learnt from Dilbert" (or similar) - so I was gad Niall looked into > > > > Yeah, the classic (that is, for me; lots of ppl out there do not know > it, though they should). > > > >> these and gave me feedback as well as a "full" fix > > > > Yeah, that would be nice. > > > >> So I mainly ask you to post your fix and problem description to the > >> Glorp Mailing list / Google group. It would be a pity if your fix is > > > > I posted (that is, I tried to; I hope it got there). > > > > Maybe I should reply there with a few more words... or find out if it > got there in the first place. > > > > > >> buried in some fork of Glorp. > >> > >> Joachim > > > > Herby > > > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by Esteban Lorenzano

> On 17 Aug 2017, at 10:18, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > jtuchel(a)objektfabrik.de wrote: >> Herby, >> >> my ccomments were not meant to say you are not competent enough to fix >> Glorp. I know you have been active as the maintainer of Amber for quite >> a while now and know you are an experienced Smalltalker. So this is not > > Not really. Actually, never did any production-ready project in Smalltalk. The one I do now is the first time. > >> an attempt to make you look incompetent or "unqualified". >> >> I just wanted to point out that >> >> * I think that if there is a bug in Glorp, it should be communicated >> to the maintainers in order to make sure the fix is making it into >> newer Glorp versions and from there to all dialects that have a port > > Yeah, sure. But Esteban's mail suggested that it is a long process, so maybe it _is_ beneficial to try to shortcut the fix at Pharo side. > > Don't know the local politics, so can't say myself. Is not about politics :) basically: cincom does not maintains other platforms than themselves (and *I am not* complaining, this is a fair choice, we do the same with pharo related things). So if we want to keep the port updated is this community who has to do it. Now, in the case of Glorp this is not easy to do and last year we (the consortium) spent money to get an updated port. Now, if there is a bug and is *we* who found it, I would like to have a fix for our port (and of course inform it to cincom guys). In factâ¦ complexity is so big in this project that every port of Glorp from VW to Pharo is a âde factoâ fork (not desired, but necessary). And any new port/update of the port will require important efforts we cannot do at the moment (I guess we could diff versions and update just the changes we findâ¦ just to simplify. But still, this is a lot of work :P). Anyway, this is why if we have the opportunity to fix a bug in our platform, I would apply it regardless the cincom process (and our own update process). cheers, Esteban > >> of Glorp (Smalltalk is too much of a niche to be able to stand more >> and more niche-ification of forks and stuff, esp. for such a central >> part as Glorp which are way too important to only be maintained by >> one or two developers - which they unfortunately are, at least to my >> knowledge) > > :-( > >> * I am not sure if anybody from Cincom is listening here looking for >> Glorp problems, so I saw/see the danger of "private" fixes / forks >> * I fixed a few bugs in Glorp in the past just to find out that the >> concept was correct but the place to fix it was wrong (or at least >> would not heal all related problems). Glorp is complex and it has >> lots of layers. It is a good example of the "avoid responsibility" >> concept that was once (what a coincidence) formulated by Alan Knight >> in an article named "All I've learned about object orientation I >> learnt from Dilbert" (or similar) - so I was gad Niall looked into > > Yeah, the classic (that is, for me; lots of ppl out there do not know it, though they should). > >> these and gave me feedback as well as a "full" fix > > Yeah, that would be nice. > >> So I mainly ask you to post your fix and problem description to the >> Glorp Mailing list / Google group. It would be a pity if your fix is > > I posted (that is, I tried to; I hope it got there). > > Maybe I should reply there with a few more words... or find out if it got there in the first place. > > >> buried in some fork of Glorp. >> >> Joachim > > Herby >

Aug. 17, 2017