I am beginning to understand a possible future of computing ;)
Skybuck Flying
Now that I saw a vertex shader in action (and in the past a pixel shader) I
am beginning to understand how the future of computing could look like.
I shall try to explain some basic programming/hardware concepts below:
First of all loops are a thing of the past.
Hardware needs to have many memory cells.
The trick to future computing is to add "meta data" to these memory cells...
and also add computing capabilities to each memory cell.
So each memory cell gets meta data for example:
Cell.ID 0, Cell.ID 1, Cell.ID 2, Cell.ID 3, Cell.ID 4
All cells execute at the same time.
Now the cells could execute the same code/branch:
// for example to execute the "true" instruction pointer:
(the true instruction pointer would be a single global variable/cell)
if Cell.ID = Instruction.Pointer then
begin
execute instruction.
end;
All other cells would do nothing... or they could execute their own cells
speculatively...
However the must not disturb the "primary/true" instruction pointer and it's
fields.
First I'll explain the next concept:
Every cell gets more information that it can store... It's like every cell
gets it's own registers/fields.
For example:
Cell.FieldA : integer;
Cell.FieldB : integer;
Now the branch can be expanded to understand if this cell is for example
FieldA of the instruction for example:
if Cell.ID = Instruction.Pointer then
begin
// conclusion: I am the cell that needs to execute
if Cell.ID = Instruction.FieldA then
begin
// conclusion: I am the cell that the instruction is pointing
towards with FieldA
end;
if Cell.ID = Instruction.FieldB then
begin
// conclusion: I am the cell that the instruction is pointing
towards with FieldB
end;
end;
It's like the cells get a mind of their own... they start thinking
themselfes :)
But first let's start with the "operation code" since that's the most
important information about an instruction.
the instruction code tells us what to do for example: mov/copy, multiply,
divide, etc.
So now the cell first examines what it is that most be done:
if InstructionPointer.Code = MUL then
begin
end else
if InstructionPointer.Code = DIV then
begin
end else
if InstructionPointer.Code = MOV then
begin
end;
// etc...
Based on this conclusion the cell could decide what to do...
For example is it safe to execute speculatively ?
To understand if it's safe the cell could examine it's own instruction with
the main instruction pointer and it's possible fields for example:
if Cell.Instruction.FieldA = InstructionPointer.FieldA then
begin
// conclusion: possible conflict detected !
// cell instruction and true instruction are pointing towards the same
memory cell.
// a conflict could occur... so this cell should not execute
speculatively !
end;
Speculative execution is only allowed if it does not conflict with the
true/main instruction that needs to be executed...
The true/main instruction always needs to be executed flawlessly...
otherwise there would be no progression... and conflicts could keep
occuring... so all cells must make sure that that does not happen by using
"superior logic" ! :) = flawless logic :)
As long as it's programmed flawlessly then cells can go ahead and execute
speculatively as much as they want... if that could lead to more faster
software execution.
A counter per cell could be kept to detect by how many cells it was changed
? I am not sure if this is possible... would be great if it was possible.
If this is possible then a scan can occur to detect how many times the
instruction pointer can simply fly through all the already executed
instructions...
Well anyway that's how the future would/could look... cells with their own
data/registers and computing resources.
I am not sure but the problem with gpu's (dx9) right now could be that the
coordinates of the vertex shaders need to remain within the view
port/texture space... otherwise they would fall off and be illiminated...
and this would then not trigger any additional pixel shaders...
This is a silly opengl artifact/problem... getting rid of opengl/graphics
will solve this problem easily :)
For now I need a way to attach more data to each vertex... to store
information in them...
I believe verteces can have texture coordinates and colors... so those
fields could be used to store more information per vertex.
vertex=cell in this case.
I am not sure if it's somehow possible to attach more data to verteces ?
Would be cool...
And also how to access/retrieve this data in a vertex shader....
Maybe that's what the new "vertex-texture" functionality is for... me not
sure ;)
Anyway I am smelling some bad car/truck gasses or something in my living
room so have to do something about that.
Well so far my thoughts... lot's more thinking and investigating to do =D
Cool stuff ! ;) :)
Bye,
Skybuck =D
Ken Hagan
<Blood...@hotmail.com> wrote:
> Now that I saw a vertex shader in action (and in the past a pixel
> shader) I am beginning to understand how the future of computing
> could look like.
I think what you describe only works well on embarrassingly parallel
problems with streaming-like access patterns such as, er, graphics.
OK, I exaggerate. There are probably many significant jobs that have
sub-tasks fitting this description, but the sub-tasks are typically
"differently" embarrassingly parallel. That is, they have different
degrees of parallelism and their source and output data cut across the
dataset in different ways. Typically, the setup and harvesting required to
use GPU-style parallelism outweighs the benefits, especially since each
access to main memory now costs dozen or hundreds of cycles.
Maarten Wiltink
news:15655$4aa11ee9$d53372a9$74...@cache4.tilbu1.nb.home.nl...
[...]
> The trick to future computing is to add "meta data" to these memory
> cells... and also add computing capabilities to each memory cell.
And in the end, every memory cell is a computer again as we now
understand it.
Which is not to say that this idea is without merit. It can't be, if
(IIRC) Seymour Cray seriously proposed to build such a machine along
these lines. I think I remember this from a newspaper article about
the future of supercomputing, about fifteen years ago. It mentioned
encryption breaking as one application.
Groetjes,
Maarten Wiltink
Terry Newton
> Now that I saw a vertex shader in action (and in the past a pixel shader) I
> am beginning to understand how the future of computing could look like.
> Well anyway that's how the future would/could look... cells with their own
> data/registers and computing resources.
As a user of scientific computing this stuff is highly facinating
(and probably a bit off topic here unless a GPU Mars can be devised
but what the heck, hardly no traffic in here anyway). The 8800-series
GPU's have even more power, supporting methods like CUDA and OpenCL
(a version of OpenGL that supports gp computing). The limitations are
rather severe for a conventional-thinking programmer - the problem
has to be rewritten to fit the hardware (as much as possible).
> Well so far my thoughts... lot's more thinking and investigating to do =D
> Cool stuff ! ;) :)
Yes indeed.
On other subjects...
NTFS/Linux compatibility - NTFS isn't documented so there's no way
to guarantee 100% success. It works pretty good these days but my
advise is don't do it on an important system. But it's great for
rescuing
files off a crashed Vista laptop.
Battlefield executor - I have no use for this and the methods don't
map to how I normally evolve. Plus the .rar doesn't unpack on my
system.
For what I do I need individual pair battles that output a score, any
grid-like assumptions made by the mars makes it difficult to
impossible
to map my usual select/battle/mutate process.
However... freebasic supports multithreading... last night I threw
together
a simple evolver to test, I can set it to any number of threads. I
haven't
figured out how to make the mutex's work yet so for now the threads
just stomp on each other but it doesn't seem to care - call it
accidental
crossover. Amusingly multithreading even on a single core seems
to make it go faster. Now I guess I need a real multi-core CPU...
Terry
Skybuck Flying
generator that works by using multiple threads and harvesting race
conditions... after some first initial problems, it seemed to work well and
produce good random numbers... but from what I remember it spent a great
deal of cpu.
Now you mention using threads for evolving in a way that I haven't thought
of... using race conditions to trigger strange/weird/unpredictable
mutations... sounds kinda interesting ! :)
Maybe gpu can also be used to trigger random/weird mutations by letting the
gpu-cores race...
I used a global lehmer rng algorithm on two threads... (maybe there is a
better algorithm for this kind of thing...)
each thread executes it once and sets a boolean to true and then executes it
again and again until a third thread detects that both booleans are set to
true... it then outputs the number and sets the boolean back to false so the
next number is generated... and so forth...
It would be very funny of this could work on GPU as well... and who knows ?!
Maybe it might create even better random numbers then ever before ! ;)
Might be interesting for encryption people too ;) Like maybe generating a
"unique" signature or so... or a "unique" key... to be used for a while...
What sometimes worries me about the redcode evolver concept is that it's
still based on a pretty simple random number generator that is seeded with
time mostly... and I am a bit worried that at some point it will simply
restart completely and produce more or less the same results and leaves some
search space unexplored... that would be bad... a true random number
generator would/could probably garantue a better search space ? ;)
Bye,
Skybuck.
MitchAlsup
architecture. Used in the ICL 2900, M5, Bouroughs B5000 and B6000
series computers. This computation style fell out of favor in the
early 1980s for a variety of reasons. These machines were adapt at
doing things like computing ALGOL parameter 'thunks', and some LISP
stuff. Had they not made the mistake of placing too much of the
security, rights and protection mechanisms in the 'cell.ID' they would
have probably gone farther.
Mitch
nm...@cam.ac.uk
That last is doubtful. The reasons for ICL's failure were not the
architecture - I know less about Burroughs, but I doubt that they
were for that, either. Replace "would have probably" by "might
have".
Regards,
Nick Maclaren.
Skybuck Flying
I will look for one myself now... then I go write some Free Basic code for
fun :)
(GPU can wait a bit ;) :))
Bye,
Skybuck ! =D
Skybuck Flying
http://fbide.freebasic.net/index.php?menuID=56
Looks like a nice one ! ;)
Bye,
Skybuck.
Skybuck Flying
Only real complaint I have about it is the annoying beep whenever it does a
compile&run but that's solved by setting the speaker volume to low...
Further it seems to be very high quality.
Basic nice editor with some syntax highlighting
Good help file.
Good compiler with advanced free basic features it seems.
Good error reporting.
(No debugger ? lol)
I am writing a nice battlefield evolver in it... this will function as an
example how to write a basic battlefield evolver for my battlefield
executor... it's also an example of some nice things like binary file
support etc.
I think I will actually use free basic for now to do some evolver
experiments or so ;)
Furthermore free basic is very samiliar to delphi in many ways... basic ways
:)
(I wish free basic had some better file input and output routines... I had
to write those myself.. but this will do for now ! ;))
Stay tuned for the sources, the will be open source and in the public
domain... it will be niccce ! =D
And you, Tery, can probably learn lot's of it... because so far your code
seems pretty messy (you write some spaghetti code :))
I hope you do learn how to program structured and/or object oriented (those
both more or less the same)
(Free basic doesn't have support for inheritance... that would probably be
pushing it a bit... but it's ok)
Soon the code will be released... first I want to get it done... a basic
evolver... to be sure everything is working nicely... and to test the
battlefield executor ofcourse.
And then you can try to modify it or learn from it.. and try to implement
your new evolver idea's into it... that would be nice...
You would be a bit restricted because the warriors fight on a battlefield...
but besides from that you can still do all kinds of evolving...
And quite frankly... with 1 v 1 mode... it would act pretty much as a
normal/regular evolver... only difference is 9 warriors fight for one
cell... and the one with the best score wins....
So this battlefield executor will do just fine as a replacement for pmars !
For the time being you know...
Bye,
Skybuck.
Skybuck Flying
I am very impressed by the Free Basic language ! =D
It's much much much better than I thought.
As I program and program more in it I discover it's almost as powerfull as
Delphi...
Except Free Basis doesn't have inheritance.
Well I have already spent a whole day on implement my published binary file
format for the Battlefield Executor/Evolver... and gjez ! Is it a lot of
work !
Holyprogramming batman ! ;)
I am still not done but soon I will be done hopefully !
And then you gonna get a load of total awesomeness ! ;) =D LOL
Bye,
Skybuck.
Terry Newton
> Hmm...
>
> I am very impressed by the Free Basic language ! =D
>
> It's much much much better than I thought.
I'm having trouble getting multi-threading to work right
under FreeBasic for Windows. I have MUCH more to
say about this (preferably just to rgc) but I'm not able
to post reliably to usenet, my ISP dropped support, etc
so I have to use google groups, and it doesn't seem to
be working right today.
Terry
Skybuck Flying
For some reason this crashes during the deletes:
type TBattlefield
private:
declare sub ReSize( ParaHeight as integer, ParaWidth as integer )
public:
mWarrior(0,0) as TWarrior pointer rem (y,x)
end type
sub TBattlefield.Resize( ParaHeight as integer, ParaWidth as integer )
dim vY as integer
dim vX as integer
for vY = 0 to mHeight-1
for vX = 0 to mWidth-1
if (vX >= ParaWidth) or (vY >= ParaHeight) then
delete mWarrior(vY,vX)
endif
next
next
rem now resize the array
redim preserve mWarrior( ParaHeight-1, ParaWidth-1 ) as Twarrior pointer
rem create additional warriors
for vY = 0 to ParaHeight-1
for vX = 0 to ParaWidth-1
if (vX >= mWidth) or (vY >= mHeight) then
mWarrior(vY,vX) = new Twarrior()
endif
next
next
rem (if successfull) then store the the width and height
mHeight = ParaHeight
mWidth = ParaWidth
end sub
test cases fail at the end:
rem battlefield settings
print "Changing width to 5:"
mBattlefield->Width = 5
sleep
print "Changing height to 4":
mBattlefield->Height = 4
sleep
print "Changing width to 10":
mBattlefield->Width = 10
sleep
print "Changing height to 9":
mBattlefield->Height = 9
sleep
print "Changing width to 3":
mBattlefield->Width = 3
sleep
print "Changing height to 2":
mBattlefield->Height = 2
sleep
SHIT
Any idea what's wrong, or is it just a bug in free basic ?!?!?
Bye,
Skybuck.
Skybuck Flying
First the problem appeared to be with a destructor...
But then I figured it out I think...
Free Basic is more or less based on C++ and it probably doesn't have
multi-dynamic arrays like Delphi has...
C++ only has single dimension array like so:
temp = new object[100];
delete[] temp;
So I am gonna try that next ! ;)
Bye,
Skybuck.
Skybuck Flying
Took like a couple of hours or so to figure that out gjez !
(IDE had missing documentation...)
Finally I decided to look-up on the online-help... that helped a lot !
Well my time is up for today.
I do not want to post/release/publish half-finished code so it's gonna take
another day to finish things up.
As long as I don't run into any other problems with free basic or my
battlefield executor... then I should be done by tomorrow... that should/is
gonna be cool ! =D
So stay tuned tomorrow ! ;) :)
I think I might even update the specification and the executor to be more
efficient.
Probable changes could be:
1. Alpha channel for warrior colors removed.
2. Unused addressing bits used for internal/external.
3. Executor loads last battlefield, executes it, and then overwrites it with
results.
(Otherwise duplicates would exist... and that would be a waste of space...
also this way nobody else has to do the overwriting...)
4. Evolver will load last battlefield if available (seek is needed)
(Otherwise evolver will generate one)
5. Evolver will then mutate it, and save/append it to the back of the file.
(I am not yet sure if free basic can do seek to end of file... but probably
!)
Hmm I just had a new idea:
* brand new idea * YES FRESH FRESH FRESH :) *
At the back of the file there will be a special 64 bit counter.
This counter specifies where the last battlefield starts (because
battlefields are variable it's impossible to know where the last one starts
by just calculating with offsets...)
This counter will probably just be a positive position from the start of the
file.
This way the evolver and battlefield executor can both:
1. First seek to end of file - 8
2. Read 8 byte counter.
3. If successfull then seek(counter)
4. Try load battlefield from there.
This way lightning fast loading.
When battlefields are added they previous battlefield counter should be left
intact...
So the format will simply be expanded with:
<rest>
<previous battlefield position>
Exact details will follow once I know how the seek function works in free
basic.. I am not sure if it's absolute or relative ;)
a counter of -1 should indicate no more previous battlefields.
Bye,
Skybuck.
Terry Newton
> I'm having trouble getting multi-threading to work right
> under FreeBasic for Windows. I have MUCH more to
> say about this (preferably just to rgc) but I'm not able
> to post reliably to usenet, my ISP dropped support, etc
> so I have to use google groups, and it doesn't seem to
> be working right today.
I fixed the problem - was passing a pointer to an
index to indicate thread number but by the time the
thread launched the index changed. Multi-threading
works fine now under Windows/FreeBasic.
Seriously, g.g. interferes with my posting and
I have no other option. I'd show you the code but
it won't let me, so later it'll show up on my
pages. Usenet is too much effort so for now
I'm done with it (email me if you want to discuss).
Terry
Skybuck Flying
multi-dynamic array features ;)
But I think I can manage that ! ;)
As long as the pointers/objects can be reassigned no problemo ! ;)
Bye,
Skybuck.
Skybuck Flying
few more minutes in it... it will be done...
Maybe then you can take over and add some evolving code and some other stuff
would be cool.
Bye,
Skybuck.
Skybuck Flying
following code:
function ReadByteFromStream( ParaStream as integer, byref ParaByte as byte )
as integer
print "kutkut1"
dim vStartPosition as longint
dim vStopPosition as longint
print "kutkut2"
*** CRASHES HERE ***
vStartPosition = seek( ParaStream )
get #ParaStream, ,ParaByte
vStopPosition = seek( ParaStream )
print "kutkut3"
if (vStopPosition - vStartPosition) = SizeOf(byte) then
return true
end if
return false
end function
I don't know why it crashes... it was working fine in a small read test
program... hmm
Bye,
Skybuck.
Skybuck Flying
to the advanced topics...
The IDE help mostly limits itself to the basic things...
Anyway thanks to the advanced online help I should be able to write some
better code tomorrow for a couple of things....
Since these read/write routines are/were pretty horrible :)
But for now I am signing off for today !
Laterzz !
Bye,
Skybuck.
"Skybuck Flying" <Blood...@hotmail.com> wrote in message
news:43a3f$4aa2d062$d53372a9$17...@cache2.tilbu1.nb.home.nl...
Skybuck Flying
and the Bouroughs B5000...
That last one is somewhere out of the 1950's !
Pretty impressive to see something like that back then... though did it
actually work ? ;) Or was it a half-baked effort ? :)
Anyway I also learned something which I probably forgot or maybe not:
ALGOL is the grand-daddy of pretty much all modern languages... like C and
especially PASCAL/DELPHI.
ALGOL means:
Algorithm Language !
How cool is that !
And the best thing is... it looks like PASCAL.
So that means Pascal owns always ! =D
^^ Yup: ALGOL from the 1950's and 1960's ! ^^
Thx for the history lesson and
Bye,
Skybuck.
"MitchAlsup" <Mitch...@aol.com> wrote in message
news:c424cec1-a124-486d...@m38g2000yqd.googlegroups.com...
Robert Myers
> So far I checked out the ICL 2900...
>
> and the Bouroughs B5000...
>
> That last one is somewhere out of the 1950's !
>
Pretty amazing decade, the fifties.
IBM developed Stretch
http://www.brouhaha.com/~eric/retrocomputing/ibm/stretch/
with a list of notable and durable architectural innovations.
The hydrogen bomb was developed, and the Interstate Highway System was
undertaken.
And, oh, yes, the home I spent the early years of my life in got
indoor plumbing and the small town it was in got a municipal water
system.
Is computer science taught as a completed subject, as if everything
had been discovered yesterday or at some indeterminate time? Physics
and mathematics both take note of when and how something was first
understood. Different people may understand the subjects in different
ways, but some, including me, remember most of the material as
"history."
Robert.
zzbu...@netscape.net
Well, the way in which computer science was established, it would
have to be that way. Since the assumptions that a computer program
would inevitably and soon pass the Turing Test.
But the way they programmed then is also why people
soon began work on Laser I/O systems, Optical Computers,
Electronic Libraires Remote sensors, Self-Assembling Robots
Autonomous Vehilces, Holographics, network publishing,
Weather Satellites, Self-Replicating Machines, Shrink Wrap
Cybernetics,
Self-Replicating Machines, Operating System Invariant Coding,
Distributed Processing Software,
and most of the stuff people work on today.
>
> Robert.
Skybuck Flying
I think I solved this problem now with a much better general ReadFromStream
function:
function ReadFromStream( ParaStream as integer, Buffer as any ptr, Size as
integer ) as integer
dim vBytesRead as integer
get #ParaStream, ,*CPtr( byte ptr, Buffer ), Size, vBytesRead
return vBytesRead
end function
So I'll be on my way now... little example usage:
dim vLongint as longint
dim vInteger as integer
dim vWord as ushort
dim vByte as ubyte
dim vFileStream as integer
rem find first free file handle
vFileStream = freefile
rem open "test.dat" as binary filestream
open "test.dat" for binary as #vFileStream
dim vBytesRead as integer
vBytesRead = ReadFromStream( vFileStream, @vLongint, SizeOf(longint) )
print using "bytes read: ## value: ##################"; vBytesRead,
vLongint
vBytesRead = ReadFromStream( vFileStream, @vInteger, SizeOf(integer) )
print using "bytes read: ## value: ###############"; vBytesRead,
vInteger
vBytesRead = ReadFromStream( vFileStream, @vWord, SizeOf(ushort) )
print using "bytes read: ## value: ###########"; vBytesRead, vWord
vBytesRead = ReadFromStream( vFileStream, @vByte, SizeOf(ubyte) )
print using "bytes read: ## value: #####"; vBytesRead, vByte
sleep
rem close binary filestream
close #vFileStream
Bye,
Skybuck.
Skybuck Flying
strangely enough these crash, very weird:
function ReadByteFromStream( ParaStream as integer, byref ParaByte as byte )
as integer
dim vBytesRead as integer
get #ParaStream, ,ParaByte, SizeOf(byte), vBytesRead
if vBytesRead = SizeOf(byte) then return true
return false
end function
function ReadShortFromStream( ParaStream as integer, byref ParaShort as
short ) as integer
dim vBytesRead as integer
get #ParaStream, ,ParaShort, SizeOf(short), vBytesRead
if vBytesRead = SizeOf(short) then return true
return false
end function
function ReadIntegerFromStream( ParaStream as integer, byref ParaInteger as
integer ) as integer
dim vBytesRead as integer
get #ParaStream, ,ParaInteger, SizeOf(integer), vBytesRead
if vBytesRead = SizeOf(integer) then return true
return false
end function
function ReadLongintFromStream( ParaStream as integer, byref ParaLongint as
longint ) as integer
dim vBytesRead as integer
get #ParaStream, ,ParaLongint, SizeOf(longint), vBytesRead
if vBytesRead = SizeOf(longint) then return true
return false
end function
Maybe stream needs to be byref... maybe get needs to do some kind of
updating to it or so..
Bye,
Skybuck.
Skybuck Flying
My guess is... free basic still a bit buggy ! ;)
I am hoping the ReadFromStream function continues to work otherwise I am
gonna get a bit pissed off ;) :)
I am not gonna release any code if it's not working ! :) :( :) :( :) ;)
Bye,
Skybuck.
Skybuck Flying
Free basic is designed a bit weird...
get and put parameters are a bit weird and inconsistent... but it's ok... I
finally figured it out...
Ammount means "number of variables" and not "number of bytes"...
So all I need to do to make the read integer function work is set ammount to
1 to read one integer.. otherwise a buffer overrun would probably occur !
(Good thing windows has memory protection ! ;) It warned many times...)
Now the issue should be fixed here is full code with examples for read
functions:
(Now I should be done in a snap... no fixing required for my code so that's
cool... )
I was beginning to loose faith in freebasic.... but it appears to work.
So far there are a couple of things that I find instatisfactory:
1. if...then, the "then" is not needed and could be scrapped from the
language, or made optional that would code most more pleasantly.
2. get/put functions weird.
3. no debugger... but in a way... having no debugger is kinda interesting...
this forces me to read the documentation over and over until I find the
solution... with a debugger I might have been wasting more time try to
figure out what's going on ! LOL ;) :)
rem *** start of code ***:
const false = 0
const true = 1
function ReadByteFromStream( ParaStream as integer, byref ParaByte as byte )
as integer
dim vBytesRead as integer
get #ParaStream, ,ParaByte, 1, vBytesRead
if vBytesRead = SizeOf(byte) then return true
return false
end function
function ReadShortFromStream( ParaStream as integer, byref ParaShort as
short ) as integer
dim vBytesRead as integer
get #ParaStream, ,ParaShort, 1, vBytesRead
if vBytesRead = SizeOf(short) then return true
return false
end function
function ReadIntegerFromStream( ParaStream as integer, byref ParaInteger as
integer ) as integer
dim vBytesRead as integer
get #ParaStream, ,ParaInteger, 1, vBytesRead
if vBytesRead = SizeOf(integer) then return true
return false
end function
function ReadLongintFromStream( ParaStream as integer, byref ParaLongint as
longint ) as integer
dim vBytesRead as integer
get #ParaStream, ,ParaLongint, 1, vBytesRead
if vBytesRead = SizeOf(longint) then return true
return false
end function
function ReadFromStream( ParaStream as integer, ParaBuffer as any ptr,
ParaSize as integer ) as integer
dim vBytesRead as integer
get #ParaStream, ,*CPtr( byte ptr, ParaBuffer ), ParaSize, vBytesRead
return vBytesRead
end function
sub main
dim vLongint as longint
dim vInteger as integer
dim vWord as short
dim vByte as byte
dim vFileStream as integer
rem find first free file handle
vFileStream = freefile
rem open "test.dat" as binary filestream
open "test.dat" for binary as #vFileStream
dim vBytesRead as integer
if true = false then
Seek vFileStream, 1
vBytesRead = ReadFromStream( vFileStream, @vLongint, SizeOf(longint) )
print using "bytes read: ## value: ##################"; vBytesRead,
vLongint
vBytesRead = ReadFromStream( vFileStream, @vInteger, SizeOf(integer) )
print using "bytes read: ## value: ###############"; vBytesRead,
vInteger
vBytesRead = ReadFromStream( vFileStream, @vWord, SizeOf(ushort) )
print using "bytes read: ## value: ###########"; vBytesRead, vWord
vBytesRead = ReadFromStream( vFileStream, @vByte, SizeOf(ubyte) )
print using "bytes read: ## value: #####"; vBytesRead, vByte
sleep
seek vFileStream, 1
endif
if ReadLongintFromStream( vFileStream, vLongint ) = true then
print using "longint read: ###################"; vLongint
endif
if (ReadIntegerFromStream( vFileStream, vInteger ) = true) then
print using "integer read: ##########"; vInteger
endif
if (ReadShortFromStream( vFileStream, vWord ) = true) then
print using "word read: #####"; vWord
endif
if (ReadByteFromStream( vFileStream, vByte ) = true) then
print using "byte read: ###"; vByte
endif
rem extra parenthesis don't matter ;)
if (ReadLongintFromStream( vFileStream, vLongint ) = true) then
print using "longint read: ###################"; vLongint
endif
if (ReadIntegerFromStream( vFileStream, vInteger ) = true) then
print using "integer read: ##########"; vInteger
endif
if ReadShortFromStream( vFileStream, vWord ) = true then
print using "word read: #####"; vWord
endif
if ReadByteFromStream( vFileStream, vByte ) = true then
print using "byte read: ###"; vByte
endif
rem close binary filestream
close #vFileStream
end sub
main
print "press enter to terminate"
rem wait for a key press
sleep
rem *** end of code ***
Bye,
Skybuck.
Skybuck Flying
1. Replace all for selected text
2. Quickly delete spaces/lines.
But ok so far so good...
(Also it asks stupid questions:)
3. Do you want to save ?
4. Do you want to use new file ?
^ Get rid of that ;) (but I can't no options for it ! ;))
Bye,
Skybuck.
Skybuck Flying
specification.
I just checked loading a battlefield.dat in Delphi.
Apperently booleans in Delphi are 1 byte...
Last time I checked it was 4 bytes ?!?
Very strange !
Hmm...
Bye,
Skybuck.
Skybuck Flying
examples ! ;)
http://cid-aedd0ea32d61bc86.skydrive.live.com/home.aspx
Bye,
Skybuck.
Tim McCaffrey
<c424cec1-a124-486d...@m38g2000yqd.googlegroups.com>,
Mitch...@aol.com says...
Well, the Burroughs B5000/6000 should have gone further, but its not dead.
See Unisys MCP systems (Currently called Clearpath Libra).
- Tim
MitchAlsup
> In article
> <c424cec1-a124-486d-8f13-b7f42add3...@m38g2000yqd.googlegroups.com>,
> MitchAl...@aol.com says...
I am aware of that, SkyBusk is obviously not.