AltME groups: search

Let us know if this continues Max. File sharing has been disabled 
on this world, but there seems to be a glitch. I haven't seen it, 
and it's cleared up for others, so you may be our special test case 
to help track it down.

Is there a log file mode to activate?

I sometimes see a bit of CPU usage with this AltME world.

Bug: I just posted in Core group. There was a delay before the message 
was echoed back to me, so before that happened I switched to another 
group to continue reading. Then I switched back to Core, and found 
my message echoed properly. However, my message was still in the 
New message text entry area.

Altme is getting exeedingly slow in posting messages ... is this 
a network issue or some type of inherent lack of scalability?

about 5 seconds for a post for me. not slower than usual.

Graham -- please try an experiment:
-- Hop over to rebol-gate [id: guest password: guest]
-- Make a few posts in the Playpen group

rebol-gate is a tiny world, so it may help pinpoint if the problem 
is a world scaling issue.

Thanks. 

That's useful evidence that the problem is not network or server 
related [rebol3 and rebol-gate run on the same server]


Next step ---  is it better or worse in groups with many messages? 
(ie is the problem the world or the group):

--could you try a test post or two in a couple of groups that have 
less than 100 posts?
  list available here: http://www.rebol.org/aga-index.r

-- Do you have a _lot_ of private messages between you and Chris?

-- Do you see similar delays when private messaging with other members 
of this world?

[It could be that the private message distribution process is affected, 
while the broadcast of public messages is  not]

but 7 seconds to send a private message

a simple load indication from the server could tell something

so if you've PM many times in the past with anyone, it all adds up. 
 this *is* a design issue.

some groups also have started to become rather slow (the view group, 
for example)

Hmm, so if Graham rejoined as GChiu (say) he'd have an empty private 
message set, and his messaging would be fast again....

....Sounds like a good justification for a second account for a prolific 
member of a busy world.

....Or for AltME to provide a purging mechanism for old private messages.

My whole REBOL3 world data is a mere 62M on disk. Any noticeable 
slowdown occurring for this puny amount of data is somewhat .... 
surprising, to stay polite.

Well, it surely does not post back the whole chatset just for adding 
a single message ...

I am a politician - I do many behind-the-scenes activity :-)

Doesn't the speed also have to do with the message limit per chat 
settings? I've decreased mine and  it's much faster. Though I do 
wonder how accurate that setting is or what it really measures. I 
set mine to a higher number after a search and warning that it needs 
to be set higher. I've thought that there's no way there could be 
that many messages (several 1000's) in that one topic.

Plus the [web-public] groups have a fast search on REBOL.org
    http://www.rebol.org/aga-search.r

19.set is a puny 4.2mb

:) It's one of the larger ones, I'd guess, even if Maxim is just 
ahead.

If you send a private message to yourself -- is that fast or slow?

that message was not even a blip

a little spike when posting here ( reaches two bars )

I've had to restart AltMe a couple times today, just to clear the 
unsent message field.

5 seconds for me.  No other bugs with AltME for the most part.

I have learned though that if you have a message ready to be sent, 
and change groups a few times, when you hit send, it is not 100% 
sure it will be sent to the corrrect group.

My guess is that it's the server that takes time to append the message 
in the chat file.

Dunno if it does a simple append to the file but if it needs to load 
it in memory, append the block, then write it down to disk, it could 
explain why bigger chat files take longer to update !!

Looking at my Altme file activity (Filemon) when I post a message 
:

- Nothing happens until the server has done its job and send back 
the new message for the corresponding group/user.

- Then I see that the corresponding chat file is wrote entirely by 
block of 4096B !

- Then the state file (chatMYALTMEID) is updated (wrote by chunk 
of 4096B).

[I'm just guessing here] There are at least three different data 
sets to update when I send a private message to (say) Graham:
-1- my chat local *.set file

-2- whatever data sets are held on the server to record the message 
(I have no idea what these are)
-3- Graham's local *.set file


The first two could contribute to perceived slowness in sending; 
the third to any apparent slowness in updating/downloading messages.


Append/lines to a 4.5 meg file does not take long on my machine (not 
does read/lines) so I'm primed to suspect the problem is on the server.


What would be interesting to know is if the grayness I see when sending 
a message ends when:
-a- the server acknowledges receipt; or
-b- when the server has finished committing all its updates.


If it is -b-, then moving the server response to be -a- could create 
a significant perceived increase in responsiveness.

James : It would be interesting for us if you can look the file activity 
of a world server when a new post is send.

I use Filemon from Sysinternals (no included in Process monitor) 
for that.
Can you test this for us and tell us what happens ?

Also, technically, a given send box should be directly connected 
to the given group, so you can send, and even if it is in transit 
or waiting you can go on and work on other messages.

We do tag messages this way in Qtask, but we have seen this same 
bug, but don't have proof (as I do in AltME) that it is the program 
and not the operator.  But I'm always on the look out for it since 
it can be a very dangerous bug for some people.


This whole class of issue falls to a perceived form of latency, and 
a series of features are needed to suppress it.  For example, instead 
of graying the out going message area, just make it look like it 
was sent, but also instantly add a “message hour glass” in the “New 
message” bar when on that group, and, also create a new tinted empty 
box in the thread saying something like “Waiting for new message 
to post”.


This frees you up to go elsewhere.  If you come back to the same 
group it is clear what state it is in.  If you want to retrieve the 
sent message just click on the “Message hour glass” and it will bring 
it back into the input box.


Lastly, of course, if you try to leave AltME before it is done sending, 
need to offer people a dialog warning them , and giving them access 
to the messages waiting.

There is more, but yeah, it takes a lot to make this work.

Reichart, I agree, all those features would be a tremendous improvement.

4:57:00.5195412 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: 
Sequential Access, Synchronous IO Non-Alert, Non-Directory File, 
Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Opened

4:57:00.5198317 PM	altme.exe	1492	QueryInformationVolume	C:\Program 
Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:00.5200764 PM	altme.exe	1492	QueryAllInformationFile	C:\Program 
Files\altme\servers\nakakihara\chat\18.chg	BUFFER OVERFLOW	CreationTime: 
2/12/2010 1:20:09 PM, LastAccessTime: 9/25/2010 4:55:35 PM, LastWriteTime: 
9/25/2010 4:55:35 PM, ChangeTime: 9/25/2010 4:55:35 PM, FileAttributes: 
A, AllocationSize: 296, EndOfFile: 292, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x1000000002fd2, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:00.5209299 PM	altme.exe	1492	QueryStandardInformationFile	C:\Program 
Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	AllocationSize: 
296, EndOfFile: 292, NumberOfLinks: 1, DeletePending: False, Directory: 
False

4:57:00.5211763 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	Offset: 
292, Length: 4

4:57:00.5215235 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	

4:57:00.5243792 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:00.5246281 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\chat	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:00.5248293 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\chat	SUCCESS	

4:57:00.5248513 PM	altme.exe	1492	IRP_MJ_CLOSE	C:\Program Files\altme\servers\nakakihara\chat	SUCCESS	

4:57:00.5256763 PM	altme.exe	1492	QueryInformationVolume	C:\Program 
Files\altme\servers\nakakihara\chat\18.set	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:00.5259221 PM	altme.exe	1492	QueryAllInformationFile	C:\Program 
Files\altme\servers\nakakihara\chat\18.set	BUFFER OVERFLOW	CreationTime: 
2/12/2010 1:20:09 PM, LastAccessTime: 9/25/2010 4:57:00 PM, LastWriteTime: 
9/25/2010 4:57:00 PM, ChangeTime: 9/25/2010 4:57:00 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x1000000002fd3, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:00.5263666 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
0, Length: 4,096

4:57:00.5267764 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	FAST 
IO DISALLOWED	Offset: 4,096, Length: 4,096

4:57:00.5270125 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
4,096, Length: 4,096

4:57:00.5277232 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
8,192, Length: 4,096

4:57:00.5280137 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
12,288, Length: 4,096

4:57:00.5282825 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	FAST 
IO DISALLOWED	Offset: 16,384, Length: 4,096

4:57:00.5285077 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
16,384, Length: 4,096

4:57:00.5288736 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
20,480, Length: 3,470

4:57:00.5291306 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	

4:57:00.5292988 PM	altme.exe	1492	IRP_MJ_CLOSE	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	

4:57:00.5299280 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\registry.chg	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: 
Sequential Access, Synchronous IO Non-Alert, Non-Directory File, 
Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Opened

4:57:00.5301501 PM	altme.exe	1492	QueryInformationVolume	C:\Program 
Files\altme\servers\nakakihara\registry.chg	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:00.5303400 PM	altme.exe	1492	QueryAllInformationFile	C:\Program 
Files\altme\servers\nakakihara\registry.chg	BUFFER OVERFLOW	CreationTime: 
2/12/2010 1:19:53 PM, LastAccessTime: 9/25/2010 4:55:35 PM, LastWriteTime: 
9/25/2010 4:55:35 PM, ChangeTime: 9/25/2010 4:55:35 PM, FileAttributes: 
A, AllocationSize: 77,824, EndOfFile: 74,727, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x1000000002e83, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:00.5305657 PM	altme.exe	1492	QueryStandardInformationFile	C:\Program 
Files\altme\servers\nakakihara\registry.chg	SUCCESS	AllocationSize: 
77,824, EndOfFile: 74,727, NumberOfLinks: 1, DeletePending: False, 
Directory: False

4:57:00.5307507 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\registry.chg	SUCCESS	Offset: 
74,727, Length: 4

4:57:00.5317625 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\registry.chg	SUCCESS	

4:57:00.5355275 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\registry.set	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:00.5357293 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:00.5358812 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara	SUCCESS	

4:57:00.5359027 PM	altme.exe	1492	IRP_MJ_CLOSE	C:\Program Files\altme\servers\nakakihara	SUCCESS	

4:57:00.5366269 PM	altme.exe	1492	QueryInformationVolume	C:\Program 
Files\altme\servers\nakakihara\registry.set	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:00.5368179 PM	altme.exe	1492	QueryAllInformationFile	C:\Program 
Files\altme\servers\nakakihara\registry.set	BUFFER OVERFLOW	CreationTime: 
2/12/2010 1:19:53 PM, LastAccessTime: 9/25/2010 4:57:00 PM, LastWriteTime: 
9/25/2010 4:57:00 PM, ChangeTime: 9/25/2010 4:57:00 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x300000000002e84, EaSize: 
0, Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:00.5371021 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\registry.set	SUCCESS	Offset: 
0, Length: 3,544

4:57:00.5374496 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\registry.set	SUCCESS	

4:57:00.5375367 PM	altme.exe	1492	IRP_MJ_CLOSE	C:\Program Files\altme\servers\nakakihara\registry.set	SUCCESS	

4:57:04.5427517 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\registry.set	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:04.5429673 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:04.5431218 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara	SUCCESS	

4:57:04.5431436 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara	SUCCESS	

4:57:04.5438713 PM	altme.exe	12200	QueryInformationVolume	C:\Program 
Files\altme\worlds\nakakihara\registry.set	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:04.5440655 PM	altme.exe	12200	QueryAllInformationFile	C:\Program 
Files\altme\worlds\nakakihara\registry.set	BUFFER OVERFLOW	CreationTime: 
2/21/2010 8:17:46 PM, LastAccessTime: 9/25/2010 4:57:04 PM, LastWriteTime: 
9/25/2010 4:57:04 PM, ChangeTime: 9/25/2010 4:57:04 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x50000000026e1, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:04.5443479 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\registry.set	SUCCESS	Offset: 
0, Length: 3,298

4:57:04.5452260 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\registry.set	SUCCESS	

4:57:04.5453489 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\registry.set	SUCCESS	

4:57:04.5535307 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\state	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:04.5537371 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:04.5538911 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara	SUCCESS	

4:57:04.5539140 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara	SUCCESS	

4:57:04.5545705 PM	altme.exe	12200	QueryInformationVolume	C:\Program 
Files\altme\worlds\nakakihara\state	SUCCESS	VolumeCreationTime: 2/12/2010 
10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: True, 
VolumeLabel: 

4:57:04.5547627 PM	altme.exe	12200	QueryAllInformationFile	C:\Program 
Files\altme\worlds\nakakihara\state	BUFFER OVERFLOW	CreationTime: 
2/21/2010 8:17:46 PM, LastAccessTime: 9/25/2010 4:57:04 PM, LastWriteTime: 
9/25/2010 4:57:04 PM, ChangeTime: 9/25/2010 4:57:04 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x100000000da8a, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:04.5550102 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\state	SUCCESS	Offset: 
0, Length: 184

4:57:04.5552809 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\state	SUCCESS	

4:57:04.5553641 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\state	SUCCESS	

4:57:04.5712081 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:04.5714824 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:04.5716849 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	

4:57:04.5717076 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	

4:57:04.5725515 PM	altme.exe	12200	QueryInformationVolume	C:\Program 
Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:04.5727921 PM	altme.exe	12200	QueryAllInformationFile	C:\Program 
Files\altme\worlds\nakakihara\chat\18.set	BUFFER OVERFLOW	CreationTime: 
2/21/2010 8:18:22 PM, LastAccessTime: 9/25/2010 4:57:04 PM, LastWriteTime: 
9/25/2010 4:57:04 PM, ChangeTime: 9/25/2010 4:57:04 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x100000000dac0, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:04.5732424 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
0, Length: 4,096

4:57:04.5736452 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	FAST 
IO DISALLOWED	Offset: 4,096, Length: 4,096

4:57:04.5738807 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
4,096, Length: 4,096

4:57:04.5742406 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
8,192, Length: 4,096

4:57:04.5745250 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
12,288, Length: 4,096

4:57:04.5747951 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	FAST 
IO DISALLOWED	Offset: 16,384, Length: 4,096

4:57:04.5750261 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
16,384, Length: 4,096

4:57:04.5753840 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
20,480, Length: 3,467

4:57:04.5756441 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	

4:57:04.5761567 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	

4:57:04.5788099 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:04.5790912 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:04.5792937 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	

4:57:04.5793150 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	

4:57:04.5801410 PM	altme.exe	12200	QueryInformationVolume	C:\Program 
Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:04.5803791 PM	altme.exe	12200	QueryAllInformationFile	C:\Program 
Files\altme\worlds\nakakihara\chat\chat4	BUFFER OVERFLOW	CreationTime: 
2/21/2010 8:18:23 PM, LastAccessTime: 9/25/2010 4:57:04 PM, LastWriteTime: 
9/25/2010 4:57:04 PM, ChangeTime: 9/25/2010 4:57:04 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x100000000dadf, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:04.5807059 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	Offset: 
0, Length: 2,206

4:57:04.5810769 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	

4:57:04.5811630 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	

4:57:04.6485821 PM	altme.exe	12200	QueryOpen	C:\WINDOWS\system32\msimtf.dll	SUCCESS	CreationTime: 
3/31/2003 5:00:00 AM, LastAccessTime: 9/25/2010 4:56:24 PM, LastWriteTime: 
8/4/2004 12:56:43 AM, ChangeTime: 2/13/2010 12:50:11 AM, AllocationSize: 
159,744, EndOfFile: 159,232, FileAttributes: A

4:57:04.6488903 PM	altme.exe	12200	CreateFile	C:\WINDOWS\system32\msimtf.dll	SUCCESS	Desired 
Access: Execute/Traverse, Synchronize, Disposition: Open, Options: 
Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: 
Read, Delete, AllocationSize: n/a, OpenResult: Opened

4:57:04.6493828 PM	altme.exe	12200	CreateFileMapping	C:\WINDOWS\system32\msimtf.dll	SUCCESS	SyncType: 
SyncTypeCreateSection, PageProtection: PAGE_EXECUTE

4:57:04.6494085 PM	altme.exe	12200	QueryStandardInformationFile	C:\WINDOWS\system32\msimtf.dll	SUCCESS	AllocationSize: 
159,744, EndOfFile: 159,232, NumberOfLinks: 1, DeletePending: False, 
Directory: False

4:57:04.6494267 PM	altme.exe	12200	FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION	C:\WINDOWS\system32\msimtf.dll	SUCCESS	

4:57:04.6494462 PM	altme.exe	12200	CreateFileMapping	C:\WINDOWS\system32\msimtf.dll	SUCCESS	SyncType: 
SyncTypeOther

4:57:04.6494602 PM	altme.exe	12200	FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION	C:\WINDOWS\system32\msimtf.dll	SUCCESS	

4:57:04.6496560 PM	altme.exe	12200	CloseFile	C:\WINDOWS\system32\msimtf.dll	SUCCESS	

4:57:04.6496803 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\WINDOWS\system32\msimtf.dll	SUCCESS

This is very interesting ... I was trying to post to a group and 
got "internet busy ..." so instead of restarting Altme I opened up 
another Altme client and can post merrily away

it's a bug

I get "stuck on internet busy"  often... 


when I have an issue with it... I just close altme and start a new 
one... it takes 5 seconds so its not a big deal.

I'm getting "Internet busy" a lot too.

I've just posted twice privately to Graham, and each time it took 
too long for the message to be echoed back to me, so I switched groups 
to continue reading. After a few minutes, I went back and the message 
had appeared. However, in both instances, my message was not cleared 
from the New message entry area, so I had to clear it manually.

Might be because I have a lot of private messages?

Under Ubuntu10.04, the function "copy to the clipboard" is local 
to ALTME only, This means that I cannot use it to copy an url or 
a text to another program or document. Any correction ?

Thank you from a linux newcomer ;-)

I think I need to get a Graham2 account ... posting PMs is taking 
over 10 seconds to what seems like a minute sometimes.

I'll set you up a second account for testing Graham.

48 seconds to post a PM to Sunanda :(

I also have a fairly large private messages file.

Try with someone who does not -- say a Hello message to a new member.

its become slow for everyone.  is it time to start up a new world... 
or update the server its running on?

if we do make a new world, I'd name it differently than just going 
to rebol4... its misleading.

so it doesn't seem to mean a PM message store issue

Debugging without the source is a little silly

Very slow for me right now. Inconsistently so though. I doubt it's 
flat files at fault. I think it's the sync/diff/publish model that 
doesn't scale. Only a guess since I don't have the code.

I'm pretty sure the current behaviour is the better one.... and why 
something can be larger?
>> to-integer #"a"
== 97
>> to-integer #"A"
== 65

>> (1 * #"a") = (1 * to integer! #"a")
== true

I guess, the question is, whether chars should be more number-like 
or more string-like. In R2, chars are number-like except in maybe 
PARSE, where they are string-like:

>> parse "a" [#"A"]
== true

even if:

>> #"a" = #"A"
== false


In R3, chars are somewhere in between being number-like and string-like, 
as I see it. We can still do much calculations with chars, but not 
all:

>> 2 * #"a"
== 194
>> 2 ** #"a"

** Script error: ** does not allow char! for its exponent argument


The last is possible in R2. If chars should be more string-like, 
then make them so, Carl! This is really confusing:

>> "a" > "A"
== false
>> #"a" > #"A"
== true

There was a big debate about this before we hammered down the current 
equivalence hierarchy, including the operators. There was even a 
suggestion to have ~= refer to EQUAL?, making = refer to EQUIV?, 
but we finally decided that the paying attention to binding and exact 
IEEE754 equivalence was too advanced for most uses, so = was assigned 
to the most forgiving form of equality. Many other languages with 
an equivalence hierarchy have made a similar choice, so it shouldn't 
be too surprising.

The last is only confusing, if chars are considered string-like, 
as in R3. In R2, #"a" being greater than #"A" makes good sense.

In general, doing math with char! values without explicitly converting 
them is kind of bad form; it leads to developer confusion. The main 
reason you'd do this is because of the awkwardness of combining operator 
and prefix expressions without parentheses. It's interesting that 
it still works in some cases, but not in others. Considering characters 
to be number-like is a bit weird, a bit too C-like for my tastes.

For instance:
>> 1 + #"a"
== 98
>> #"a" + 1
== #"b"


The latter looks alright to me, the former looks weird, like a to-integer 
is missing. Can't say why though. I know why the result is an integer! 
(the left side sets the datatype returned most of the time), but 
any math that treats a char! as a number rather than as a non-numeric 
ordinal value just seems weird to me.

Alright, not "most of the time", just in this case. For others:
>> 1 + 1.0
== 2.0
>> 1 + $1
== $2
>> 1 + 100%
== 2.0


Maybe that's why it seems weird. I guess that since R3 char! values 
are currently limited to the codepoints in the BMP they are 16 bits, 
so converting back to char! would be a potential loss of range. It 
could go either way, so I guess the datatype-on-the-left rule is 
a way for the developer to specify which they want. And that rule 
applies to string types too (for INSERT and APPEND), so it's not 
completely weird.

Now this looks completely weird:
>> #"a" + #"b"
== #"A"


Having ordinal values that you wouldn't think of being numbers act 
like numbers seems really weird to me. I can accept that #"a" > #"A", 
but treating them like numbers without explicit conversion seems 
strange to me. I get similarly creeped out by multiplying one money! 
by another; I have to remember that despite the "$", and "money!" 
name, they aren't really money (a measure of quantity), they are 
just another numeric encoding that enables more precise decimal math 
than decimal! (another name that seems off to me, since its values 
are floating-point binary, not decimal).

I don't like this inconsistency though:
>> "a" > "A"
== false
>> #"a" > #"A"
== true

Too bad we don't have a hierarchy of inequalities. Only two levels 
would be needed. Maybe a /case option to the functions that the the 
operators map to? Is it even possible to map an op! to a function 
that can take an option?

Perhaps the relative comparison functions could be made to all be 
case-insensitive (for datatypes that have case defined as a concept), 
and have additional STRICT-* case-sensitive functions which would 
combine the functions and STRICT-NOT-EQUAL?.

We have a ticket for an improved equality comparison hierarchy:
http://www.curecode.org/rebol3/ticket.rsp?id=1834

I think that would nicely fit with a inequality comperison hierarchy 
as well (strict vs non-strict).

Andreas, given that Carl is one of the ones who was tripping over 
the equivalence hierarchy (that he helped decide on) that ticket 
looks pretty promising. The caveat is that Ladislav is the one who 
would likely be doing the work, and he seems to need some convincing. 
Plus, it would require a new R3 release, not just a host kit update.

Ladislav is the one who would likely be doing the work, and he seems 
to need some convincing

 - I do agree, that LESSER? etc. functions having two versions (or 
 a refinement, or something) would be useful.

A test of SIZE-TEXT shows a bug in R2. This should hopefully not 
be present in R3.

The test to run:

f: make system/standard/font [name: "Verdana" size: 12]
g: make gob! []
t: import 'text
g/text: bind [font f bold true text "Boo"] t
probe size-text g				; I get 26x14 here
g/text: bind [font f bold false text "Boo"] t
probe size-text g				; I get 25x14 here


It's possible that the result may vary, but the bold version should 
produce a wider size than the normal one. if you can test this similarly 
to what you did for R2, that would be great. Thanks.

wish for R3 / Topaz / Red / World:
Add common charsets and parsing rules to system object:
system/parse: context [
	digit: charset [#"0" - #"9"]
	upper: charset [#"A" - #"Z"]
	lower: charset [#"a" - #"z"]
	alpha: union upper lower
	hexdigit: union digit charset "abcdefABCDEF"
	bindigit: charset "01"
	space: charset " ^-^/"
	digits: [some digit]
	decimal: [opt digits "." digits | digits "." ]
	exponent: [ [ "e" | "E" ] opt ["+" | "-"] digits]
	float: [opt "-" [decimal | digits] opt exponent]
	email:...
	...etc.
]

No need to add them to the system opject in R3, just export them 
from a module and they'll be available. They should be made read-only 
for security, but this is a good idea.

The Rebol system object is a very nice thing. I would pack it with 
all sort of things, especially those that can be "global" to a program 
or even "global" to many Rebol programs.

wish for R3 / Topaz / Red / World:

I wish that refinements would be totally reworked (not R2 compatible 
:( ).

Current situation with some examples:

view/new/title/offset/options win "Dialog" 20x20 'resize

remove_last: func [{remove last (n) element(s) of a series}
	serie [series!] /n num [integer!]
	][
	num: any [num 1]
	remove/part skip tail serie negate num num
]


append: func [{Appends a value to the tail of a series and returns 
the series head.} 
    series [series! port!] value /only
	][
    head either only [
        insert/only tail series :value
    ] [
        insert tail series :value
    ]
]

New situation with different syntax and default values:

view win /new true /title "Dialog" /offset 20x20 /options 'resize

remove_last: func [{remove last (n) element(s) of a series}
	series [series!] /n: 1 [integer!]
	][
	remove skip tail series negate n /part n
]


append: func [{Appends a value to the tail of a series and returns 
the series head.} 
    series [series! port!] value /part /only /dup
	][
    head insert tail series :value /part part /only only /dup dup
]


Note that append could also be redifined as: #macro append [] [head 
insert tail]

Make your own then :)  I'm not blowing you off, it's a real suggestion.

Macros make a lot more sense in compiled languages like Red, Topaz 
(to JS) and World (to bytecode) than they do in interpreted code-is-data-at-runtime 
languages like R3, where most functions are like macros.

One thing you might have to consider with your refinement suggestion 
is that you would have to put a lot of parentheses around function 
calls, because otherwise your syntax would make it ambiguous which 
function the refinement applies to. This is similar to the situation 
with Smalltalk and Objective-C.

R3 operations that would be slower than R2:

- Bulk string handling, because strings are twice as big (Unicode).

- Word dereferencing for function-context words, because they are 
stack-relative, adding an indirection.

- The fixed overhead of LOAD (like header handling) because it does 
a lot more.
Any others?

(This is continued from #World, where it was a little off-topic)

I haven't compared operator evaluation yet, which was another major 
change between R2 and R3. Overall, R3 looks a little worse for C-like 
code than R2, though neither are really appropriate for that kind 
of thing. And yet in my tests (which I don't have the results of 
handy, so take that with a grain of salt) idiomatic R3 is faster 
than idiomatic R2 for REBOL-like tasks, and the R3 idioms are less 
awkward to write than the R2 idioms. How have the rest of you found 
the differences to be in your work?

It should be if you are doing the loop directly from the console 
or otherwise using a object/module/script/closure context rather 
than in a function.

There are a lot of problems with R3 on OSX, and different problems 
with R2. Annoying.

Could be. I need pragmas in a few places, but I haven't dug deeply 
into that area of compilation. It's boring, I think. :) And I haven't 
had time to look at things like LLVM, but that would probably solve 
some problems and speed things up even more.

R3 is typically about a third faster than R2 in my tests on Linux, 
even with my CMS that mostly does text processing

Neither R2 nor R3 considers it to be a problem making this directory 
in WinXP:

make-dir %.../


but the directory is never made, as far as I can tell. Doing it from 
a command prompt returns that the directory already exists.

Do you think this is a bug?

When I try to make three dot dir under Vista, it returns an error, 
and hence R3 hould return an error too imo. Ditto for invalid chars, 
not allowed being a part of the dir names ...

There is a cross-platform bug in R3 where it won't see any file or 
directory that starts with two periods, not just . and .. - the ticket: 
http://issue.cc/r3/1899

The particular error triggered in the Windows console when you try 
to make a directory with only periods in its name is that the directory 
already exists; this is probably a bad error. However, when you try 
to MAKE-DIR directories that already exist in REBOL, it's a noop, 
not an error. That is probably why it's not triggering an error here.

wish for R3 / Topaz / Red / World:

callback! datatype so you can "really" use a lot of nice shared libraries.

Do you have a simple example?

Right. Red/System seems vary nice.

I am waiting for floats to be implemented in Red/System. Is there 
a "math" library that could be used intead?

With R3 you can just callback functions if you want a synchronous 
call, or callback through an event if you want to go asynchronous.

Still, a generator of marshalling wrapper functions would be nice, 
especially since REBOL and C don't have similar data models.

But R3 can't deal very good with multi-threaded libs. You need to 
trick it: Use async with non or integer value to trigger a sync call 
on Rebol side.

Well, it is not a big "disaster" for me, since it is not too hard 
for me to adjust the function I am writing for R3 with just a slight 
modification of the behaviour...

Cyphre, it's not a good approach in R3

To track newly defined words in a context you can check the source 
of the function INTERN.

Its tracking newly "created" words in the user context after a binding. 
It's maybe not what you're trying to do but it was in response to 
Cyphre.

However, I do not track "modified", since that is a bit more complicated/slower 
than I like.

Steeve... I guess Ladislav is looking for something like this R2 
helper script:
gbl-test: func [
    code
    /all
    /init {returns string with all global variables set to none}
    /local gbl-list words str_init
][
    words: make block! 50
    str_init: make string! 1000
    gbl-list: query/clear system/words
    do code
    if block? gbl-list: query system/words [
        foreach item gbl-list [
            if any [all value? item] [
                insert tail words to-word item
                if init [
                    insert tail str_init join to-word item ": "
                ]
            ]
        ]
    ]
    if init [
        write clipboard:// join str_init "none"
    ]
    words
]
>> gbl-test [a: 1]
== [a]
>> f: func[a][b: a + 1] gbl-test [f a: 1]
== [a b]

>> gbl-test [ o: context [a: 1] ]
== [o]
>> gbl-test [ o: context [a: 1 set 'b 2] ]
== [b o]

Ok ok, but I just want to have a look on the functions Cyphre pointed 
out :)

Not a waste ... it has provided the drive to produce derivatives

but its missing a few key things which prevent a few few of us from 
moving to it.

No, there was already a drive to produce derivatives, because it 
wasn't good enough, and it was killed