[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'

	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'

--- The full stack ---
CompressedSources(Object)>>doesNotUnderstand: #setConverterForCode
FileDirectory class>>openSources:andChanges:forImage:
CompressedSources class>>internalizeSources:
[] in PragmaPreference>>rawValue:

Did I load the right version, and do you have any idea how to solve this? :-)


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