- Pharo-users - lists.pharo.org

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

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

by Herby VojÄÃk

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. > 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

Re: [Pharo-users] GTInspect auto-update in raw view?

by Esteban Lorenzano

> On 17 Aug 2017, at 01:02, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hello Esteban, > > You can enable auto-refresh with: GTInspector enableStepRefresh > For performance reasons it is disabled by default. If you are curious why I think Andrei could explain a bit more :) I want to know why is disabled and more than that, when will we be able to make it enabled by default, as before. Esteban > > Cheers, > Alex > > On 17 August 2017 at 00:56, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > Hi all, > > Is there a way to enable the auto-update of instance variables display in the GTInspector? > > There are cases where the instance is nil, I then initialize it somehow, but the variable is still displayed as nil. > > I know there is an "Update" button, which BTW should be labeled "refresh" instead, to do it manually, but hey, this is Smalltalk, we invented MVC :D > > We can consider the previous as a feature, but what I think it is a bug is that if the variable is nil, and later it is initialized, nil is still displayed, but when clicked the nodes below it shows the variables of the new object in the instance variable. > > E.g. > <image.png> > > Is this a bug or a feature? > > Regards! > > Esteban A. Maringolo >

Aug. 17, 2017

Re: [Pharo-users] Loading PharoJS Re: PharoJS

by Nicolai Hess

Hi Pierce 2017-06-25 13:07 GMT+02:00 Pierce Ng <pierce(a)samadhiweb.com>: > Just tried loading PharoJS with this snippet: > > Gofer it > smalltalkhubUser: 'noury' project: 'PharoJS'; > configuration; > loadStable > > Loaded cleanly on a fresh 32-bit Pharo-50772 image. Ran almost half the > tests > during which it created/deleted tabs on my open Chromium browser > repeatedly. > Then the tests started a new instance of my default browser (which happens > to > be Midori) and here seemingly the web socket stuff didn't work so well, so > I > aborted the tests, but this I attribute to Midori not PharoJS. > > On a fresh 64-bit Pharo-60501 image, while loading > PharoJSBridge-NouryBouraqadi-120, error encountered: > > SyntaxError: Variable or expression expected > Object as yet unclassified makeInspect > > makeInspect. > Variable or expression expected-><javascript: 'blah blah > blah blah > }'> > > I think the problem is the '.' dot after the selector name. This is not valid code for a method definition. I think this was an error on this parser to allow the code in the first place. Now we "fixed" the parser to indicate this as an error. Of course it would be good to replace / fix the method definition right on this debugger window, and move on with loading th code. But I am afraid this does not work. So, someone (with an older Pharo version where this code gets compiled) need to load the package and fix the method > Closing the error alert box brought up a debugger at > RBParser>>parserError:. > > Any idea what to fix, anyone? > > Pierce > > >

Aug. 17, 2017

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

by jtuchel＠objektfabrik.de

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 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 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 these and gave me feedback as well as a "full" fix 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 buried in some fork of Glorp. Joachim Am 16.08.17 um 20:02 schrieb Herby VojÄÃk: > Esteban A. Maringolo wrote: >> Herby, >> >> Please apologize I can't take the time to look into your code. > > Np, if someone eventually will. > >> I granted you write access to >> <http://smalltalkhub.com/#!/~DBXTalk/Glorp/>, could you upload your >> latter version to it? > > Uploaded. > >> Regards! >> Esteban A. Maringolo > > P.S.: I did not gain understanding of Glorp innards in that small > amount of time, of course, but I went by the intuition that at the > place I made the fix, the normal (base class, Mapping >>) behaviour is > to convert the right sides of the relation, and the only subclass > which has it overridden, namely DirectMapping, seems to do the same > thing (when looking at the code), just in an optimized way. Except, it > does not convert, which I believe, strongly, to be a bug left out > while doing that optimization. > > Herby > > -- ----------------------------------------------------------------------- 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] GTInspect auto-update in raw view?

by Aliaksei Syrel

Hello Esteban, You can enable auto-refresh with: GTInspector enableStepRefresh For performance reasons it is disabled by default. If you are curious why I think Andrei could explain a bit more :) Cheers, Alex On 17 August 2017 at 00:56, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi all, > > Is there a way to enable the auto-update of instance variables display in > the GTInspector? > > There are cases where the instance is nil, I then initialize it somehow, > but the variable is still displayed as nil. > > I know there is an "Update" button, which BTW should be labeled "refresh" > instead, to do it manually, but hey, this is Smalltalk, we invented MVC :D > > We can consider the previous as a feature, but what I think it is a bug is > that if the variable is nil, and later it is initialized, nil is still > displayed, but when clicked the nodes below it shows the variables of the > new object in the instance variable. > > E.g. > [image: ImÃ¡genes integradas 1] > > Is this a bug or a feature? > > Regards! > > Esteban A. Maringolo >

Aug. 16, 2017