CurrentReadOnlySourceFiles annoys me ...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

CurrentReadOnlySourceFiles annoys me ...

marcel.taeumel
Hi there!

The following snippet does not work:

[(Morph >> #submorphCount) getSource]
        on: Exception
        do: [:ex | ]

Because "CurrentReadOnlySourceFiles" is a subclass of Exception. This smells. Does somebody know, why?

Rationale: I want to catch all exceptions in some silently but frequently called method.

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Levente Uzonyi
CurrentReadOnlySourceFiles could have been a ProcessLocalVariable, but at
the time I added it, there were no PLVs in the Trunk. Changing it to PLV
is possible, but it would take some effort.

Catching all exceptions doesn't sound like a good idea. Why would you want
to do that?

Levente

On Wed, 16 Dec 2015, marcel.taeumel wrote:

> Hi there!
>
> The following snippet does not work:
>
> [(Morph >> #submorphCount) getSource]
> on: Exception
> do: [:ex | ]
>
> Because "CurrentReadOnlySourceFiles" is a subclass of Exception. This
> smells. Does somebody know, why?
>
> Rationale: I want to catch all exceptions in some silently but frequently
> called method.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

marcel.taeumel
I want to catch all exceptions because it is kind of test code where only success matters. :-)  It is an experiment where the participants should program stuff and receive a green tick whenever the task is accomplished. Raising a debugger when the participant puts a "self halt" or anything into the control flow of the test code would confuse the participant.

Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank you for the explanation. Can you sketch the steps to transform that into a PLV? Why would it take some effort?

Bset,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Eliot Miranda-2
Hi all,

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

_,,,^..^,,,_ (phone)

> On Dec 16, 2015, at 4:38 AM, marcel.taeumel <[hidden email]> wrote:
>
> I want to catch all exceptions because it is kind of test code where only
> success matters. :-)  It is an experiment where the participants should
> program stuff and receive a green tick whenever the task is accomplished.
> Raising a debugger when the participant puts a "self halt" or anything into
> the control flow of the test code would confuse the participant.
>
> Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank
> you for the explanation. Can you sketch the steps to transform that into a
> PLV? Why would it take some effort?
>
> Bset,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Levente Uzonyi
My objection is that concurrent access of the read-only source files would
cause race conditions.
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 Trunk.

Levente

On Wed, 16 Dec 2015, Eliot Miranda wrote:

> Hi all,
>
>    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 debuggers 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.
>
> _,,,^..^,,,_ (phone)
>
>> On Dec 16, 2015, at 4:38 AM, marcel.taeumel <[hidden email]> wrote:
>>
>> I want to catch all exceptions because it is kind of test code where only
>> success matters. :-)  It is an experiment where the participants should
>> program stuff and receive a green tick whenever the task is accomplished.
>> Raising a debugger when the participant puts a "self halt" or anything into
>> the control flow of the test code would confuse the participant.
>>
>> Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank
>> you for the explanation. Can you sketch the steps to transform that into a
>> PLV? Why would it take some effort?
>>
>> Bset,
>> Marcel
>>
>>
>>
>> --
>> View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

timrowledge

> On 16-12-2015, at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:
>
> My objection is that concurrent access of the read-only source files would cause race conditions.
> 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 Trunk.

One of the best ways to avoid file read (and many write) issues would be to get rid of the {deletable expletive} stupid separate move & read/write operations. If the primitive were readBytes: num from: file to: buffer at: startposition and so on a lot of problems could not exist. It’s like error codes being found via a distinct api instead of being returned directly - a catastrophe waiting to happen.



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
This is all a lot simpler and a lot more complicated than you could possibly imagine



Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Eliot Miranda-2
In reply to this post by Levente Uzonyi
Hi Levente,

On Wed, Dec 16, 2015 at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:
My objection is that concurrent access of the read-only source files would cause race conditions.
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 Trunk.

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 VisualWorks and with 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 :-)

 


Levente


On Wed, 16 Dec 2015, Eliot Miranda wrote:

Hi all,

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

_,,,^..^,,,_ (phone)

On Dec 16, 2015, at 4:38 AM, marcel.taeumel <[hidden email]> wrote:

I want to catch all exceptions because it is kind of test code where only
success matters. :-)  It is an experiment where the participants should
program stuff and receive a green tick whenever the task is accomplished.
Raising a debugger when the participant puts a "self halt" or anything into
the control flow of the test code would confuse the participant.

Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank
you for the explanation. Can you sketch the steps to transform that into a
PLV? Why would it take some effort?

Bset,
Marcel



--
View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.







--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Eliot Miranda-2
In reply to this post by timrowledge


On Wed, Dec 16, 2015 at 3:29 PM, tim Rowledge <[hidden email]> wrote:

> On 16-12-2015, at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:
>
> My objection is that concurrent access of the read-only source files would cause race conditions.
> 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 Trunk.

One of the best ways to avoid file read (and many write) issues would be to get rid of the {deletable expletive} stupid separate move & read/write operations. If the primitive were readBytes: num from: file to: buffer at: startposition and so on a lot of problems could not exist. It’s like error codes being found via a distinct api instead of being returned directly - a catastrophe waiting to happen.

Agreed.  How do we make this so?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
This is all a lot simpler and a lot more complicated than you could possibly imagine






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

David T. Lewis
In reply to this post by Eliot Miranda-2
On Wed, Dec 16, 2015 at 06:49:20PM -0800, Eliot Miranda wrote:

> Hi Levente,
>
> On Wed, Dec 16, 2015 at 2:43 PM, Levente Uzonyi <[hidden email]>
> wrote:
>
> > My objection is that concurrent access of the read-only source files would
> > cause race conditions.
> > 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 Trunk.
>
>
> 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 VisualWorks and with 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 :-)
>

The CurrentReadOnlySourceFiles changes were added in March 2011 in
Files-ul.104 and Files-ul.105. I do not recall the specific problems that
motivated this change, but they were real problems and I don't think that
it was anything related to the debugger. Levente can probably refresh
our collective memory but I think that it may have been something related
to running SUnit tests or the MC update stream processing.

Be that as it may, it seems to me that accessing source files entries
is a fundamental thing that needs to work reliably in a multi-process
environment, period (*).

Dave

(*) I was tempted to say "without exception" rather that "period", but
that would imply an implementation bias ;-)


Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

timrowledge
In reply to this post by Eliot Miranda-2

> On 16-12-2015, at 7:24 PM, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Wed, Dec 16, 2015 at 3:29 PM, tim Rowledge <[hidden email]> wrote:
>
> > On 16-12-2015, at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:
> >
> > My objection is that concurrent access of the read-only source files would cause race conditions.
> > 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 Trunk.
>
> One of the best ways to avoid file read (and many write) issues would be to get rid of the {deletable expletive} stupid separate move & read/write operations. If the primitive were readBytes: num from: file to: buffer at: startposition and so on a lot of problems could not exist. It’s like error codes being found via a distinct api instead of being returned directly - a catastrophe waiting to happen.
>
> Agreed.  How do we make this so?

Extended FilePlugin for new systems, maintain old api as well for a few years until all users of the old stuff die, new images use new prims. If there are particularly annoying users of the old stuff, send out ninja teams to expedite their retirement.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: ESR: Emulate Slide Rule



Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

marcel.taeumel
In reply to this post by marcel.taeumel
We might want to add something to support this:

[ ... ]
   on: Exception - CurrentReadOnlyFiles
   do: [:ex | ... ].

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Levente Uzonyi
In reply to this post by marcel.taeumel
On Wed, 16 Dec 2015, marcel.taeumel wrote:

> I want to catch all exceptions because it is kind of test code where only
> success matters. :-)  It is an experiment where the participants should
> program stuff and receive a green tick whenever the task is accomplished.
> Raising a debugger when the participant puts a "self halt" or anything into
> the control flow of the test code would confuse the participant.

In that case, you should catch subinstances of Exception. An Exception is
not an Error, it won't raise a debugger. Actually it will do nothing by
default.
IMHO you should catch what needs to be cached:
  Error, Abort, UnhandledError, Halt
>From that list, Abort seems to be unused in the image, so it's a candidate
for removal.

>
> Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank

It is an exception. You "throw" it, and when it's resumed, it'll contain
read-only source files.

> you for the explanation. Can you sketch the steps to transform that into a
> PLV? Why would it take some effort?

Make a new PLV variable which implements the same API, then rewrite the
users. It takes effort, because it must work while it's being used.


Levente

>
> Bset,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Levente Uzonyi
In reply to this post by Eliot Miranda-2
Hi Eliot,

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 can lead to the problems I've
described. IIRC Seaside has such example service.

Levente

On Wed, 16 Dec 2015, Eliot Miranda wrote:

> Hi Levente,
> On Wed, Dec 16, 2015 at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:
>       My objection is that concurrent access of the read-only source files would cause race conditions.
>       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 Trunk.
>
>
> 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 VisualWorks and with
> 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 :-)
>
>  
>
>
>       Levente
>
>       On Wed, 16 Dec 2015, Eliot Miranda wrote:
>
>             Hi all,
>
>                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 debuggers
>             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.
>
>             _,,,^..^,,,_ (phone)
>
>                   On Dec 16, 2015, at 4:38 AM, marcel.taeumel <[hidden email]> wrote:
>
>                   I want to catch all exceptions because it is kind of test code where only
>                   success matters. :-)  It is an experiment where the participants should
>                   program stuff and receive a green tick whenever the task is accomplished.
>                   Raising a debugger when the participant puts a "self halt" or anything into
>                   the control flow of the test code would confuse the participant.
>
>                   Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank
>                   you for the explanation. Can you sketch the steps to transform that into a
>                   PLV? Why would it take some effort?
>
>                   Bset,
>                   Marcel
>
>
>
>                   --
>                   View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html
>                   Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>

Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Eliot Miranda-2
Hi Levente,

On Fri, Dec 18, 2015 at 4:05 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

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 can lead to the problems I've described. IIRC Seaside has such example service.

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 (IDE) priority would use it.  What do you think, worse than the disease, or acceptable?
 


Levente

On Wed, 16 Dec 2015, Eliot Miranda wrote:

Hi Levente,
On Wed, Dec 16, 2015 at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:
      My objection is that concurrent access of the read-only source files would cause race conditions.
      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 Trunk.


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 VisualWorks and with
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 :-)

 


      Levente

      On Wed, 16 Dec 2015, Eliot Miranda wrote:

            Hi all,

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

            _,,,^..^,,,_ (phone)

                  On Dec 16, 2015, at 4:38 AM, marcel.taeumel <[hidden email]> wrote:

                  I want to catch all exceptions because it is kind of test code where only
                  success matters. :-)  It is an experiment where the participants should
                  program stuff and receive a green tick whenever the task is accomplished.
                  Raising a debugger when the participant puts a "self halt" or anything into
                  the control flow of the test code would confuse the participant.

                  Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank
                  you for the explanation. Can you sketch the steps to transform that into a
                  PLV? Why would it take some effort?

                  Bset,
                  Marcel



                  --
                  View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html
                  Sent from the Squeak - Dev mailing list archive at Nabble.com.







--
_,,,^..^,,,_
best, Eliot







--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Frank Shearar-3
In reply to this post by marcel.taeumel
On 18 December 2015 at 14:34, marcel.taeumel <[hidden email]> wrote:
> We might want to add something to support this:
>
> [ ... ]
>    on: Exception - CurrentReadOnlyFiles
>    do: [:ex | ... ].

In other words, #- returns an ExceptionSet of some kind. Maybe a
special kind of ExceptionSet that can represent an infinitude of
Exceptions.

That ought to be fairly simple to implement. It just needs to have a
#handle: that says something like

handle: anException
    ^ (anException isKindOf: CurrentReadOnlyFiles) not

or something. I did something similar for my experiments in delimited
dynamic binding:
https://github.com/frankshearar/Control/blob/master/packages/Control.package/DelimitedDynamicVariableSet.class/instance/handles..st

frank

> Best,
> Marcel

Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

gcotelli
In reply to this post by marcel.taeumel

I've implemented this support for Pharo a few years ago.  You can harvest it from there.  Just a couple of methods and some test cases. 

On Dec 18, 2015 11:52, "marcel.taeumel" <[hidden email]> wrote:
We might want to add something to support this:

[ ... ]
   on: Exception - CurrentReadOnlyFiles
   do: [:ex | ... ].

Best,
Marcel



--
View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867752.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.



Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Levente Uzonyi
In reply to this post by Eliot Miranda-2
Hi Eliot,

I don't see how it would be any better than the current solution.
Currently users get correct behavior no matter what they do, and get
good performance if they add some extra code (CurrentReadOnlySourceFiles
cacheDuring: [ ... ]).
With your suggestion, users would have to add some extra code to get
correct behavior.

Levente

On Fri, 18 Dec 2015, Eliot Miranda wrote:

> Hi Levente,
> On Fri, Dec 18, 2015 at 4:05 PM, Levente Uzonyi <[hidden email]> wrote:
>       Hi Eliot,
>
>       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
>       can lead to the problems I've described. IIRC Seaside has such example service.
>
>
> 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
> (IDE) priority would use it.  What do you think, worse than the disease, or acceptable?
>  
>
>
>       Levente
>
>       On Wed, 16 Dec 2015, Eliot Miranda wrote:
>
>             Hi Levente,
>             On Wed, Dec 16, 2015 at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:
>                   My objection is that concurrent access of the read-only source files would cause race conditions.
>                   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
>             Trunk.
>
>
>             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
>             VisualWorks and with
>             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 :-)
>
>              
>
>
>                   Levente
>
>                   On Wed, 16 Dec 2015, Eliot Miranda wrote:
>
>                         Hi all,
>
>                            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
>             debuggers
>                         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.
>
>                         _,,,^..^,,,_ (phone)
>
>                               On Dec 16, 2015, at 4:38 AM, marcel.taeumel <[hidden email]> wrote:
>
>                               I want to catch all exceptions because it is kind of test code where only
>                               success matters. :-)  It is an experiment where the participants should
>                               program stuff and receive a green tick whenever the task is accomplished.
>                               Raising a debugger when the participant puts a "self halt" or anything into
>                               the control flow of the test code would confuse the participant.
>
>                               Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank
>                               you for the explanation. Can you sketch the steps to transform that into a
>                               PLV? Why would it take some effort?
>
>                               Bset,
>                               Marcel
>
>
>
>                               --
>                               View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html
>                               Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>
>
>
>
>
>
>             --
>             _,,,^..^,,,_
>             best, Eliot
>
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>

Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Eliot Miranda-2


On Sat, Dec 19, 2015 at 12:51 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

I don't see how it would be any better than the current solution.

Here's why.  Right now I have to type

 CurrentReadOnlySourceFiles cacheDuring: [self systemNavigation browseAllSelect: [:m| m getSourceFromFile includesSubString: 'foo']]

instead of

        self systemNavigation browseAllSelect: [:m| m getSourceFromFile includesSubString: 'foo']

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.


Currently users get correct behavior no matter what they do, and get good performance if they add some extra code (CurrentReadOnlySourceFiles cacheDuring: [ ... ]).
With your suggestion, users would have to add some extra code to get correct behavior.

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.
 


Levente


On Fri, 18 Dec 2015, Eliot Miranda wrote:

Hi Levente,
On Fri, Dec 18, 2015 at 4:05 PM, Levente Uzonyi <[hidden email]> wrote:
      Hi Eliot,

      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
      can lead to the problems I've described. IIRC Seaside has such example service.


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
(IDE) priority would use it.  What do you think, worse than the disease, or acceptable?
 


      Levente

      On Wed, 16 Dec 2015, Eliot Miranda wrote:

            Hi Levente,
            On Wed, Dec 16, 2015 at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:
                  My objection is that concurrent access of the read-only source files would cause race conditions.
                  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
            Trunk.


            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
            VisualWorks and with
            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 :-)

             


                  Levente

                  On Wed, 16 Dec 2015, Eliot Miranda wrote:

                        Hi all,

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

                        _,,,^..^,,,_ (phone)

                              On Dec 16, 2015, at 4:38 AM, marcel.taeumel <[hidden email]> wrote:

                              I want to catch all exceptions because it is kind of test code where only
                              success matters. :-)  It is an experiment where the participants should
                              program stuff and receive a green tick whenever the task is accomplished.
                              Raising a debugger when the participant puts a "self halt" or anything into
                              the control flow of the test code would confuse the participant.

                              Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank
                              you for the explanation. Can you sketch the steps to transform that into a
                              PLV? Why would it take some effort?

                              Bset,
                              Marcel



                              --
                              View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html
                              Sent from the Squeak - Dev mailing list archive at Nabble.com.







            --
            _,,,^..^,,,_
            best, Eliot







--
_,,,^..^,,,_
best, Eliot







--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: CurrentReadOnlySourceFiles annoys me ...

Levente Uzonyi
On Sat, 19 Dec 2015, Eliot Miranda wrote:

>
>
> On Sat, Dec 19, 2015 at 12:51 PM, Levente Uzonyi <[hidden email]> wrote:
>       Hi Eliot,
>
>       I don't see how it would be any better than the current solution.
>
>
> Here's why.  Right now I have to type
>
>  CurrentReadOnlySourceFiles cacheDuring: [self systemNavigation browseAllSelect: [:m| m getSourceFromFile includesSubString: 'foo']]
>
> instead of
>
>         self systemNavigation browseAllSelect: [:m| m getSourceFromFile includesSubString: 'foo']
No, you don't have to. Caching is totally optional. But if you don't use
it, a new FileStream  will be created for every single method your code
will read.

[ CurrentReadOnlySourceFiles cacheDuring: [self systemNavigation
browseAllSelect: [:m| m getSourceFromFile asString includesSubString:
'foo']] ] timeToRun. "==> 880"

[ self systemNavigation browseAllSelect: [:m| m getSourceFromFile asString
includesSubString: 'foo'] ] timeToRun. "==> 4380"

>
> 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.
>
>
>       Currently users get correct behavior no matter what they do, and get good performance if they add some extra code (CurrentReadOnlySourceFiles cacheDuring: [ ... ]).
>       With your suggestion, users would have to add some extra code to get correct behavior.
>
>
> 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.
That was my last-resort suggestion a few mails earlier, but I still find
using a ProcessLocalVariable superior to this, since that way all
processes can have their own read-only copies. I'm not sure how well the
debugger can work with PLVs though.

Levente

>  
>
>
>       Levente
>
>       On Fri, 18 Dec 2015, Eliot Miranda wrote:
>
>             Hi Levente,
>             On Fri, Dec 18, 2015 at 4:05 PM, Levente Uzonyi <[hidden email]> wrote:
>                   Hi Eliot,
>
>                   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
>                   can lead to the problems I've described. IIRC Seaside has such example service.
>
>
>             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
>             (IDE) priority would use it.  What do you think, worse than the disease, or acceptable?
>              
>
>
>                   Levente
>
>                   On Wed, 16 Dec 2015, Eliot Miranda wrote:
>
>                         Hi Levente,
>                         On Wed, Dec 16, 2015 at 2:43 PM, Levente Uzonyi <[hidden email]> wrote:
>                               My objection is that concurrent access of the read-only source files would cause race conditions.
>                               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
>                         Trunk.
>
>
>                         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
>                         VisualWorks and with
>                         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 :-)
>
>                          
>
>
>                               Levente
>
>                               On Wed, 16 Dec 2015, Eliot Miranda wrote:
>
>                                     Hi all,
>
>                                        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
>                         debuggers
>                                     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.
>
>                                     _,,,^..^,,,_ (phone)
>
>                                           On Dec 16, 2015, at 4:38 AM, marcel.taeumel <[hidden email]> wrote:
>
>                                           I want to catch all exceptions because it is kind of test code where only
>                                           success matters. :-)  It is an experiment where the participants should
>                                           program stuff and receive a green tick whenever the task is accomplished.
>                                           Raising a debugger when the participant puts a "self halt" or anything into
>                                           the control flow of the test code would confuse the participant.
>
>                                           Conceptionally, CurrentReadOnlySourceFiles is no kind of an exception. Thank
>                                           you for the explanation. Can you sketch the steps to transform that into a
>                                           PLV? Why would it take some effort?
>
>                                           Bset,
>                                           Marcel
>
>
>
>                                           --
>                                           View this message in context: http://forum.world.st/CurrentReadOnlySourceFiles-annoys-me-tp4867253p4867327.html
>                                           Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>
>
>
>
>
>
>                         --
>                         _,,,^..^,,,_
>                         best, Eliot
>
>
>
>
>
>
>
>             --
>             _,,,^..^,,,_
>             best, Eliot
>
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>