Some parts of this message have been removed.
Learn more about Nabble's security policy.
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.
Impara Bugtracking
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,
[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.
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
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.
Some parts of this message have been removed.
Learn more about Nabble's security policy.
