Mantis working again

Hi all,

Mantis is working again, so we can get an overview of what the I/O
team has on its plate. At the moment, that's the files and networking
categories, 28 open issues in all.

A number of them have been assigned to people - I suggest these people
(moi included) work through these issues first before grabbing new
bugs. That leaves 10 bugs that need to be reviewed and classified. Any
takers?

I have attached the overview from Mantis.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2462	[Squeak] Network	minor	always	01-12-06 03:05	01-12-06 22:45
Reporter:	umejava	Platform:
Assigned To:	cdegroot	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	3.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	SocketStream raises an error in printOn:
Description:	SocketStream raises an error in printOn:, because some inst vars defined in superclass are left 'nil'. This patch overrides printOn: and makes SocketStream print out its socket status properly.
Steps To Reproduce:
Additional Information:
Attached Files:	SocketStreamPatches.1.cs (1 KB) 01-12-06 03:06

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2455	[Squeak] Network	feature	N/A	01-08-06 19:47	01-08-06 19:47
Reporter:	tb	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	3.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	WebClient class would be a good addition
Description:	We have a lot of bits and pieces of web technology laying around the image but it is not integrated into any kind of cohesive system. Recent issue WRT using MIMEDocument to deduce mime type for urls when downloading is just one instance. I would like to see a class WebClient that implements the backend of a web browser. This includes caching that obeys cache settings in the HTTP response header or META tags, cookie support, redirection following/meta refresh handling/multi threaded loading and so forth.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2454	[Squeak] Network	major	always	01-08-06 19:36	01-08-06 19:36
Reporter:	tb	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	3.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	HttpUrl>>retrieveContents does not use correct mime type
Description:	Trying to retrieve a css file from an IIS server will fail if you did something like "http://someserver.com/file.css" [^] because the ACCEPT header is not being set to text/css. There is a mime-file extensions database already in the image, we should use it specify ACCEPT headers properly. Thus, HttpUrl>>retrieveContentsArgs: args     ^self retrieveContentsArgs: args accept: 'application/octet-stream' should be changed to: HttpUrl>>retrieveContentsArgs: args     ^self retrieveContentsArgs: args accept: (MIMEDocument guessTypeFromName: self)
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2381	[Squeak] Files	minor	always	12-18-05 22:39	12-18-05 22:48
Reporter:	Eddie Cottongim	Platform:
Assigned To:	cdegroot	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	3.9
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	[BUG] MidiFileReader can't handle certain MIDI files
Description:	A few midi files throw an error(below) when loaded in squeak, but read fine with other players. I'm not sure if this some unsupported MIDI feature, a bad file, or what, but we can at least tolerate it. I put a 'isNotNil' test around the problem area and the files will read now. A problem file is included.
Steps To Reproduce:
Additional Information:	UndefinedObject(Object)>>doesNotUnderstand: #'>=' MIDIFileReader>>readTrackEvents MIDIFileReader>>readTrackContents: MIDIFileReader>>readTrackChunk [] in MIDIFileReader>>readMIDIFrom: {[self readTrackChunk]} SmallInteger(Integer)>>timesRepeat: MIDIFileReader>>readMIDIFrom: [] in ScorePlayerMorph class>>playMidiFile: {[:midiReader | f := (FileStream oldFileNamed: fullName) binary. score := (...]} SystemDictionary(Dictionary)>>at:ifPresent: ScorePlayerMorph class>>playMidiFile: SimpleServiceEntry>>performServiceFor: [] in MenuItemMorph>>invokeWithEvent: {[(selArgCount := selector numArgs) = 0 ifTrue: [target perform: selector] ...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: MenuItemMorph>>invokeWithEvent: MenuItemMorph>>mouseUp: MenuItemMorph>>handleMouseUp: MouseButtonEvent>>sentTo: MenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with:
Attached Files:	horde1.mid.gz (11 KB) 12-18-05 22:39 midibadbytefix-efc.1.cs.gz (1 KB) 12-18-05 22:47

Notes
(0003344) Eddie Cottongim    12-18-05 22:48	Attached file avoids the problem by adding a check for nil. I'd rather know why the nil is being thrown, but don't have time to check now.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2380	[Squeak] Files	minor	always	12-18-05 21:05	12-18-05 22:38
Reporter:	Eddie Cottongim	Platform:
Assigned To:	cdegroot	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	3.9
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	[BUG] [in 6905] Can't open Read Only MIDIs from File List
Description:	I wasn't sure about the category for this one... Opening read-only midis fails from the file list, apparently because StandardFileStream oldFileNamed: returns nil. This in turns seems to be because oldFileNamed: tries to assert write access to the file. The file list is using the ScorePlayerMorph>>playMidiFile: class method. This alternative snippet does work to open a midi score: (ScorePlayerMorph onMIDIFileNamed: 'C:\explode\cd archive June 11 1999\media\midi\ilr6.mid') openInWorld I'm not sure where the fault lies here.
Steps To Reproduce:
Additional Information:	UndefinedObject(Object)>>doesNotUnderstand: #binary [] in ScorePlayerMorph class>>playMidiFile: {[:midiReader | f := (FileStream oldFileNamed: fullName) binary. score := (...]} SystemDictionary(Dictionary)>>at:ifPresent: ScorePlayerMorph class>>playMidiFile: SimpleServiceEntry>>performServiceFor: [] in MenuItemMorph>>invokeWithEvent: {[(selArgCount := selector numArgs) = 0 ifTrue: [target perform: selector] ...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: MenuItemMorph>>invokeWithEvent: MenuItemMorph>>mouseUp: MenuItemMorph>>handleMouseUp: MouseButtonEvent>>sentTo: MenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatch:toSubmorphsOf: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using:
Attached Files:

Notes
(0003343) Eddie Cottongim    12-18-05 22:38	A similar problem occurs if you load a file more than once and the file handle hasn't been released. There is probably a problem trying to assert write access twice. BTW, this is on Win2K.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2161	[Squeak] Network	minor	always	11-08-05 05:19	12-10-05 20:51
Reporter:	yanni	Platform:
Assigned To:	gokr	OS:
Priority:	normal	OS Version:
Status:	confirmed	Product Version:	3.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	SocketStream>>upToAll: worked properly in 3.6, but is broken in 3.8
Description:	The 3.8 implementation uses a ReadWriteStream for the searchBuffer, instead of the String used in 3.6. The problem arises at:     searchBuffer position: nextStartOfSearch where the position cannot be reset to a position early than the read buffer. The result is that a match is never found, and the code waits for more input from the socket. A simple fix is to revert to the 3.6 version (which is likely a slow implementation). A test case is the File Upload test from Seaside, which ends up calling #upToAll: with the multipart file delimiter as the parameter.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003266) gokr    12-10-05 20:51	THis is known and one better solution is to use FastSocketStream instead, available on SM. FastSocketStream is the new implementation of SocketStream in 3.9. When/if we issue an update to 3.8 we include a fix.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2112	[Squeak] Network	minor	always	10-21-05 01:28	10-25-05 15:55
Reporter:	KenCausey	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Recategorize NetworkTests-* as Network-Tests-*
Description:	This would make it more consistent with the rest of the image and help out with tools like QualityControl that expect the tests to be in the same package with the code. However are there any tools (Monticello?) that have trouble with triple-level categories like Network-Tests-Kernel?
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0002966) andreas    10-25-05 09:00	It would be nice if we could agree on how to handle the tests. One of the reasons for *not* having tests in the same package is that it makes it possible to load the code without requiring SUnit (TestCase) to be present.
(0002972) KenCausey    10-25-05 15:55	Yes, I agree. I don't have a strong opinion either way but do lean towards not including tests in the same package. However what I would most like is consistency and so a solid decision would be good. I only filed this bug because someone (probably on IRC, I don't clearly remember) said to me that this should be fixed.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2109	[Squeak] Network	minor	always	10-21-05 00:32	10-21-05 00:57
Reporter:	KenCausey	Platform:
Assigned To:	michael	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	URI>>downloadUrl unimplemented
Description:	This method exists but only calls self halt. It looks like this might be useful in time.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2108	[Squeak] Network	minor	always	10-21-05 00:27	10-21-05 00:29
Reporter:	KenCausey	Platform:
Assigned To:	michael	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	URI>>hasRemoteContents unimplemented
Description:	URI>>hasRemoteContents is merely a call to self halt. I suspect there will be a use for this method in time.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2107	[Squeak] Network	minor	always	10-20-05 23:35	10-20-05 23:35
Reporter:	KenCausey	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open	« Return to Thread: Mantis working again LightInTheBox - Buy quality products at wholesale price Free Forum Powered by Nabble Forum Help