[squeak-dev] Why not just get rid of the sources file entirely (was: The Inbox: System-dtl.1277.mcz)
christoph.thiede at student.hpi.uni-potsdam.de
christoph.thiede at student.hpi.uni-potsdam.de
Sat Jan 29 23:09:46 UTC 2022
Hi Dave,
> If anyone has tried loading DTL-internal-sources-dtl.4.mcz from the inbox, I would be interested to hear what you think of the idea after trying it in your image. But please respond only if you have actually tried it :-)
I wanted to try it, but you already moved DTL-internal-sources-dtl.4.mcz to the treated inbox, so I loaded DTL-internal-sources-dtl.11 instead and enabled the new preference. After loading for some time, it said: MessageNotUnderstood: CompressedSources>>setConverterForCode
30 January 2022 12:07:22.939085 am
VM: Win32 - Smalltalk
Image: Squeak6.0alpha [latest update: #21121]
SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir C:\Users\Christoph\OneDrive\Dokumente\Squeak
Trusted Dir C:\Users\Christoph\OneDrive\Dokumente\Squeak\Christoph
Untrusted Dir C:\Users\Christoph\OneDrive\Dokumente\My Squeak
CompressedSources(Object)>>doesNotUnderstand: #setConverterForCode
Receiver: a CompressedSources
Arguments and temporary variables:
t1: setConverterForCode
t2: MessageNotUnderstood: CompressedSources>>setConverterForCode
t3: nil
Receiver's instance variables:
collection: '''From Squeak5.0 of 20 July 2015 [latest update: #15110] on 20 July 2015 at 4:13:52 pm'...etc...
position: 0
readLimit: 65536
writeLimit: 65536
initialPositionOrNil: nil
segmentFile: a ReadWriteStream
segmentSize: 65536
nSegments: 538
segmentTable: #(2168 13371 25000 37251 49586 62109 73771 87155 99139 109212 120...etc...
segmentIndex: 1
dirty: false
endOfFile: 35184983
FileDirectory class>>openSources:andChanges:forImage:
Receiver: FileDirectory
Arguments and temporary variables:
t1: 'C:\Program Files (x86)\Squeak\SqueakV50.sources'
t2: 'C:\Users\Christoph\OneDrive\Dokumente\Squeak\FreshTrunk.changes'
t3: 'C:\Users\Christoph\OneDrive\Dokumente\Squeak\FreshTrunk.image'
t4: a CompressedSources
t5: nil
t6: 'Squeak cannot locate &fileRef.
Please check that the file is named properly and is in the
same directory as this image....etc...
t7: 'Squeak cannot write to &fileRef.
Please check that you have write permission for this file.
You won'...etc...
Receiver's instance variables:
superclass: Object
methodDict: a MethodDictionary(size 125)
format: 65537
instanceVariables: #('pathName')
organization: ('enumeration' containingDirectory directoryEntries directoryEntry...etc...
subclasses: {UnixFileDirectory . AcornFileDirectory . MacFileDirectory . DosFileDirectory...etc...
name: #FileDirectory
classPool: a Dictionary(#DefaultDirectory->DosFileDirectory on 'C:\Users\Christoph\OneDrive\Dokumente\Squeak...etc...
sharedPools: nil
environment: Smalltalk
category: #'Files-Directories'
SmalltalkImage>>openSourceFiles
Receiver: Smalltalk
Arguments and temporary variables:
Receiver's instance variables:
globals: Smalltalk
CompressedSources class>>internalizeSources:
Receiver: CompressedSources
Arguments and temporary variables:
t1: true
t2: 'No external SqueakV50 sources file found'
Receiver's instance variables:
superclass: CompressedSourceStream
methodDict: a MethodDictionary(#asCompressedSources->(CompressedSources>>#asCom...etc...
format: 65548
instanceVariables: nil
organization: ('converting' asCompressedSources)
('file open/close' readOnlyCopy...etc...
subclasses: nil
name: #CompressedSources
classPool: a Dictionary(#CachedSources->a CompressedSources )
sharedPools: nil
environment: Smalltalk
category: #'DTL-internal-sources'
<clipped>
--- The full stack ---
CompressedSources(Object)>>doesNotUnderstand: #setConverterForCode
FileDirectory class>>openSources:andChanges:forImage:
SmalltalkImage>>openSourceFiles
CompressedSources class>>internalizeSources:
[] in PragmaPreference>>rawValue:
<clipped>
Did I load the right version, and do you have any idea how to solve this? :-)
Best,
Christoph
---
Sent from Squeak Inbox Talk
On 2022-01-20T21:50:45-05:00, lewis at mail.msen.com wrote:
> On Thu, Jan 20, 2022 at 11:43:08AM -0800, Eliot Miranda wrote:
> > Hi All,
> >
> > > On Jan 19, 2022, at 12:38 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> > >
> > > ???
> > > Hi Dave --
> > >
> > > > [...] which point the sources file no longer lives on rotating media
> > >
> > > Quick comment on this one. :-) Many computers use SSD/Flash storage these days and I am pretty sure that modern operating systems have their tricks with caching bigger files even further without the application ever noticing. However, considering external file scanners scanning for viruses, yes, it can be beneficial to avoid an extra use of some OS file API.
> > >
> >
> > Again our performance issues accessing sources on windows are much more likely to be rooted in the absurdity of opening a file for every file access, using the ugly CurrentReadOnlySources nonsense to compensate. If we were to maintain the in-image source files correctly our performance would improve markedly.
> >
> > The issue with source files is fundamentally to do with providing a way for the debugger to access source through different files while debugging source file access. A substituteSourceFilesDuring: aBlock protocol would work, be infinitely preferable than cacheDuring:. Why are we still unable to do something constructive here?
>
> Hi Eliot,
>
> I opened this thread to discuss something else. If anyone has
> tried loading DTL-internal-sources-dtl.4.mcz from the inbox, I
> would be interested to hear what you think of the idea after
> trying it in your image. But please respond only if you have
> actually tried it :-)
>
> To the question "Why are we still unable to do something
> constructive here?", I believe you are referring to the discussion
> that was taking place in the "Proper use of SourceFiles and
> "CurrentReadOnlySourceFiles cacheDuring:"" thread. Levente
> advocated using process local variables, and you advocated
> the protocol that you mention above.
>
> Levente: http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-January/218110.html
>
> Eliot: http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-January/218111.html
>
> I don't know which approach would be better. As far as I know
> neither proposal has been implemented.
>
> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220130/ff742e5b/attachment.html>
More information about the Squeak-dev
mailing list
|