<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 19, 2015 at 12:51 PM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Eliot,<br>
<br>
I don't see how it would be any better than the current solution.<br></blockquote><div><br></div><div>Here's why. Right now I have to type</div><div><br></div><div> CurrentReadOnlySourceFiles cacheDuring: [self systemNavigation browseAllSelect: [:m| m getSourceFromFile includesSubString: 'foo']]</div><div><br></div><div>instead of</div><div><br></div><div> self systemNavigation browseAllSelect: [:m| m getSourceFromFile includesSubString: 'foo']<br></div><div><br></div><div>which, frankly, is absurd. We're penalising the common case. If we provide a single read-only source file by default and have the uncommon case work around it, the common case, my daily life, is much easier.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Currently users get correct behavior no matter what they do, and get good performance if they add some extra code (CurrentReadOnlySourceFiles cacheDuring: [ ... ]).<br>
With your suggestion, users would have to add some extra code to get correct behavior.</blockquote><div><br></div><div>So what if, instead, the source files become process-aware and answer the single file if the accessor is in "the current IDE process", such that the notion of what's the owning process is weak, and by default the source files are unowned? This approach has a chance of solving the debugger issue too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><font color="#888888"><br>
<br>
Levente</font></span><div class=""><div class="h5"><br>
<br>
On Fri, 18 Dec 2015, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Levente,<br>
On Fri, Dec 18, 2015 at 4:05 PM, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
Hi Eliot,<br>
<br>
I don't remember the exact case which made the Pharo guys do this change, but if you implement a web service, which shows source code on a web page, and reads the code from the image, then a non-UI process will read the source code from SourceFiles, which<br>
can lead to the problems I've described. IIRC Seaside has such example service.<br>
<br>
<br>
For this I'd be tempted to implement something like withClonedReadOnlySourceFilesDuring: that installs a new read-only copy for the extent of a block, sort of analogous to deferred UI actions. The requirement would be that any accessor of source outside of normal user<br>
(IDE) priority would use it. What do you think, worse than the disease, or acceptable?<br>
<br>
<br>
<br>
Levente<br>
<br>
On Wed, 16 Dec 2015, Eliot Miranda wrote:<br>
<br>
Hi Levente,<br>
On Wed, Dec 16, 2015 at 2:43 PM, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
My objection is that concurrent access of the read-only source files would cause race conditions.<br>
We might simplify the thing by using the regular source files (or some shared read-only copies) when requested from the UI process, and create a read-only copy for all other processes. That would cover most potential slow-downs in the<br>
Trunk.<br>
<br>
<br>
Apart form the debugger can you think of situations in which this will really happen? I can't. If you can convince me that concurrent access is a real danger then I'll think again, but in all my time doing Smalltalk with Smalltalk-80 v2, with<br>
VisualWorks and with<br>
Croquet, Squeak and Pharo the only time this has been an issue was in the debugger debugging source file access. Given that that's easy to solve I don't see the point of living with such slow source file access for any longer :-)<br>
<br>
<br>
<br>
<br>
Levente<br>
<br>
On Wed, 16 Dec 2015, Eliot Miranda wrote:<br>
<br>
Hi all,<br>
<br>
IMO we don't need CurrentReadOnkySourceFiles, instead we should have SourceFilesArray maintain one read-only copy per source file. The objection is that using a single file will make debugging source file access break, since the<br>
debuggers<br>
own access to source will perturb the source files whose access is being debugged, but the debugger can easily temporarily install a different read-init copy whenever it accesses source, insulating the debugged code from this effect.<br>
<br>
_,,,^..^,,,_ (phone)<br>
<br>
On Dec 16, 2015, at 4:38 AM, marcel.taeumel <<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>> wrote:<br>
<br>
I want to catch all exceptions because it is kind of test code where only<br>
success matters. :-) It is an experiment where the participants should<br>
program stuff and receive a green tick whenever the task is accomplished.<br>
Raising a debugger when the participant puts a "self halt" or anything into<br>
the control flow of the test code would confuse the participant.<br>
<br>
Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank<br>
you for the explanation. Can you sketch the steps to transform that into a<br>
PLV? Why would it take some effort?<br>
<br>
Bset,<br>
Marcel<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html" rel="noreferrer" target="_blank">http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html</a><br>
Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
_,,,^..^,,,_<br>
best, Eliot<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
_,,,^..^,,,_<br>
best, Eliot<br>
<br>
</blockquote>
</div></div><br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>