[Gambas-user] Gambas 3 advancement

Doriano Blengino doriano.blengino at ...1909...
Mon Dec 20 10:01:11 CET 2010


Benoît Minisini ha scritto:
>> Pipes should not return EOF when the pipe is not closed. But they should
>> return EOF when the other side closes.
>>
>>      
> Why ?
>    
Because this is the way *all* unix routines work, and the only logical one.
> EOF() actually means "there is nothing to read anymore", which is the
> important needed information.
>    
Indeed: it means "nothing anymore", not "nothing at the moment".
> If Eof() returns TRUE only when the pipe is closed:
>
> 1) How do you know that there is nothing to read anymore?
>    
I know that there is nothing to read now, and in the future too, if 
eof() is true. If eof() is false, I know that some data could arrive, if 
not now, in the future. Try "cat", one of the simplest unix commands. It 
knows very well when there is data to read, when there is not, and when 
the pipe is closed.

> 2) What do you do for Sockets, for example?
>    
The same as pipes. If there is data to read, I read it. If there is not, 
I don't. If eof() is true, I close my local socket because the other 
peer has closed. May be I am missing something -- using your ideas, how 
can you tell that a pipe (or a remote socket) is closed or not?


>    
>> A compound control should intercept all events of its members, and raise
>> its own ones. More in general, a class which uses other classes, or
>> inherits from them, should completely own them and control the whole
>> thing, even during creation and destruction.
>>      
> That is what I mean with "solving the ValueBox problem".
>    
Sorry to having invaded your field. I was speaking more in general, not 
only ValueBox and not only events.


>> An OnIdle event would be handy, raised every time there are no other
>> events pending.
>>      
> Mmm. This will eat all the CPU...
>    
I know. I can only add that on some other system, to prevent this CPU 
eating, the Idle event has a parameter "Done" that, when set to true, 
stops further idle events (until the idle condition happens again). It 
works like this: the event loop does not find any event, and so sets 
Done=true and enters the Idle loop. The Idle loop consists in raising 
continuosly an Idle event, until an event is present in the queue, or 
Done becomes true. The Idle event handler sets Done to false if it has 
more work to do. If there is no Idle event handler, just one event is 
raised. To be more precise, other systems do not even raise this single 
event, if there is no handler to it.


>> The preprocessor could implement "#define" and use the definitions to do
>> simple token substitution (and, of course, make test on them).
>> Otherwise, you end in too many nested "#if".
>>      
> What I can do is implementin "#Const xxxx =<expr>", with<expr>  being only a
> test expression.
>
> I don't have the time to embed an entire evaluator in the compiler.
>    
I was not really thinking at evaluator/expressions... you surpassed 
me... - they are useful but one can live without. And one can live 
without "#define" for token substitution. You choose. It was only a 
suggestion.
Anyway, your idea (#const ...) does already the job I was thinking of. I 
was thinking at situations where you want to include many things in the 
program only when the os is "linux" and word length is 64 bits, for 
example. In that case, you should write many times an expression like 
"#if os="linux" and architecture="ia64"" or something like that. 
Instead, you can define once for all a "#Const linux64=true" and test 
subsequently for "#ifdef linux64" and so on. To be sincere, I don't like 
the C preprocessor, it is too simple and too powerful at the same 
time... :-)

Regards,
Doriano







More information about the User mailing list