<div dir="auto">Ah, of course inspectors and debugger don’t need this option, they use ‘self class parserClass’. But I wouldn’t add this option to the workspace, it seems unnecessary, who would need to open several workspaces with different parser settings?</div><div dir="auto"><br></div><div dir="auto">I think it would be better to reach consensus on a reasonable default (#st80?), and make it easy for people to change it if they want (in their own packages, by subclassing Parser and implementing #parserClass for example). Also, #parserClass would have to be saved first when saving packages, I think Juan recently changed this in CodePackage to avoid losing the ordering of message categories…</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 18 May 2022 at 12:40 AM Luciano Notarfrancesco <<a href="mailto:luchiano@gmail.com">luchiano@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">I think we can make it easy enough so that someone who wants to use a parser other than the default can do it, but without making more subclasses. Just move the preference to a class method in the parser, for example, so anyone can subclass it and reimplement that method and then implement #parserClass in their classes. About workspace, inspectors, debugger, etc, I wouldn’t add complexity for this particular issue, its easy enough to change the default parser to a new subclass if anyone wants to do it. IMHO.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">On Wed, 18 May 2022 at 12:29 AM Nicolás Papagna Maldonado via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 17, 2022 at 2:23 PM Hernan Wilkinson <<a href="mailto:hernan.wilkinson@10pines.com" target="_blank">hernan.wilkinson@10pines.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr">I like this idea better than the preferences... That is a good point. I would not work on the workspace though unless you subclass workspace and redefine the message to use the other parser... But I kind of like it more.</div></blockquote><div><br></div><div>In that case, we could have some UI component (a dropdown or something like that) to allow users to select the parser for that particular workspace instance.</div><div>What do you think?</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 17, 2022 at 1:31 PM Nicolás Papagna Maldonado via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr">Hi folks!<div><br></div><div>I'm somewhat late to the party. I went through the discussion and what worries me about the current proposal is that loading packages or filing in code that was developed under a particular setting might break in other images.</div><div>Also, this opens the door for creating other settings for the language, making it more difficult to understand or extend (IMHO).</div><div><br></div><div>My $0.02: how about using the machinery we already have, and letting classes define their parser by overriding #parserClass?</div><div>That way, we can use any parser we want (and customize it to tailor our needs) and it'll play nice (i think) with file outs and packages.</div><div><br></div><div>Best,</div><div>Nico PM </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 14, 2022 at 12:50 PM Juan Vuletich via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><u></u>
<div bgcolor="#ffffff">
On 5/14/2022 4:13 AM, Hilaire Fernandes via Cuis-dev wrote:
<blockquote type="cite">
<p> Yes it is fine. </p>
<p> I am wondering: when executing "PreferenceNG initialize" in an
image with vector graphics it seems to break the image. I guess
a race condition. </p>
<p> To avoid this situation, I suggest you edit this method as
follow: </p>
<p> PreferenceNG>>initialize<br>
ThePreferences ifNil: [ThePreferences _ Dictionary new].<br>
... <br>
</p>
<p> It will allow to add the new preferences from the data array
and reset the existing ones with the default values from the
array (this what happen when requesting a new preference already
in the system, it just updates the existing one). A few
limitation: </p>
<ul>
<li> It will not migrate type of existing preference (should be
done by hand by inspecting the object or removing the whole
preference and initialize again), I prevent it by purpose so a
user does not mess up with the type. </li>
<li> it will not remove deprecated preferences (the ones not
anymore in the data array). Should be removed by hand.<br>
</li>
</ul>
<p>Hilaire<br>
</p>
<div>Le 13/05/2022 à 22:42, Juan Vuletich via Cuis-dev a écrit :<br>
</div>
<blockquote type="cite">Hilaire,
please check that the use of Preference NG is reasonable.<br>
</blockquote>
<pre style="font-family:monospace">--
GNU Dr. Geo
<a href="http://drgeo.eu" style="font-family:monospace" target="_blank">http://drgeo.eu</a>
<a href="http://blog.drgeo.eu" style="font-family:monospace" target="_blank">http://blog.drgeo.eu</a></pre>
</blockquote>
<br>
I think that #initialize should discard everything and start anew.<br>
<br>
Please review the attach. It creates a new dictionary, populates it,
and only then installs it as the new ThePreferences. This is a
pattern that has been used in Squeak/Cuis many times.<br>
<br>
BTW, I removed #select:, and renamed #all to #allPreferences. I
think this makes the stuff easier to find with senders/implementors
(by reducing false polymorphism). I kept your author initials, as
this is essentially just some refactoring.<br>
<br>
Thanks,<br>
<pre cols="72" style="font-family:monospace">--
Juan Vuletich
<a href="http://www.cuis-smalltalk.org" style="font-family:monospace" target="_blank">www.cuis-smalltalk.org</a>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" style="font-family:monospace" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a href="https://github.com/jvuletich" style="font-family:monospace" target="_blank">https://github.com/jvuletich</a>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" style="font-family:monospace" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
<a href="https://independent.academia.edu/JuanVuletich" style="font-family:monospace" target="_blank">https://independent.academia.edu/JuanVuletich</a>
<a href="https://www.researchgate.net/profile/Juan-Vuletich" style="font-family:monospace" target="_blank">https://www.researchgate.net/profile/Juan-Vuletich</a>
<a href="https://patents.justia.com/inventor/juan-manuel-vuletich" style="font-family:monospace" target="_blank">https://patents.justia.com/inventor/juan-manuel-vuletich</a>
<a href="https://twitter.com/JuanVuletich" style="font-family:monospace" target="_blank">https://twitter.com/JuanVuletich</a></pre>
</div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><br>Nicolás Papagna</div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><span style="font-size:xx-small;border-collapse:collapse"><div style="font-size:small"><a href="https://10pines.com/" style="font-family:Roboto,Helvetica,Arial,sans-serif;font-size:medium" target="_blank"><img width="108" style="margin-bottom: 0.5em; font-family: Roboto, Helvetica, Arial, sans-serif;"></a><span style="font-family:Roboto,Helvetica,Arial,sans-serif;font-size:medium;color:rgb(0,0,0)"></span><h1 style="margin:0px;font-size:14px">Hernán Wilkinson</h1><h2 style="margin:0px 0px 1em;font-size:14px;color:rgb(100,100,100)">Software Developer & Coach</h2><p style="margin:0px;font-size:12px;color:rgb(100,100,100)">Alem 896, Floor 6, Buenos Aires, Argentina</p><p style="margin:0px;font-size:12px;color:rgb(100,100,100)">+54 11 6091 3125</p><p style="margin:0px;font-size:12px;color:rgb(100,100,100)">@HernanWilkinson</p></div></span></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><br>Nicolás Papagna</div></div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div>
</blockquote></div></div>