2010/1/5 Doriano Blengino <[email protected]>: > Kadaitcha Man ha scritto: >> 2010/1/4 Doriano Blengino <[email protected]>: >>> I think that there is >>> something extreme in trying to send large chunks of data in a single >>> instruction, >>> >> >> Weeeelllllll... Not necessarily. If the document is imprecise, which >> it most definitely is, it is fair to make assumptions then complain >> loudly to the developers when you find out that your assumptions are >> wrong. >> >> As for actually addressing your point, perhaps you are right, it may >> be extreme, but as it stands, gb3 does not allow for sending "large >> chunks of data in a single instruction" unless blocking is on. The >> whole point of what I was saying earlier is that gb3 has no mechanism >> for managing the transfer of such large blocks without blocking. >> > This is a contradiction. Blocking mode serves the purpose of simplicity
I disagree. Blocking mode guarantees known certainties, as defined by any number of RFC documents. > - if you want to send 700Mb in a single instruction, well, you can do > it. But you can not send 700Mb *and* want to be non-blocked! Look at this: > > write #1, my_700_mb_block > if error then... As I said, I would not, even with today's technology, ever send more than 512Kb. > In blocking mode all is fine: Not if the connection can't handle it. No disrespect here but you youngsters simply do not seem to understand the value of testing and proving. You seem to be interested only in how reasonable your own thoughts seem to yourselves. Hell, if it makes sense to you, it must be right, right? > the first instruction takes several > minutes, and then terminates either with error or by having completed > the job. The second instruction takes the appropriate actions. But if > the first statement is non-blocking, the second instruction can not test > for success or not - you should test at later time, perhaps several > hours later. So non-blocking mode raises event to notify about what > happened in background. Gibberish. Sorry. Je ne comprends pas. > Things are getting complicated... Only because you are complicating them. If I write a program to "wait until the cows come home" then wait until the cows come home the program should do, without you or the programming language deciding otherwise. Do you understand that? Really, no insult intended, but I sincerely doubt that you do understand. You seem to interpret "general purpose programming language" to mean what you and you alone consider to be reasonable. You have lost contact with the idea that a program must do exactly as it is told and nothing more. Instead you insert the idea, "What if the programmer does something they didn't mean to do? Merde! How do I deal with that?" And so you end up in the never-ending circles you are currently caught in. > No, no... I was saying that I find it "extreme" to send large chunk of > data in single instructions, No, no... I was saying that I DO NOT find it "extreme" to send large chunk of data in single instructions IF THE DOCUMENTATION IMPLIES IT IS OK. > but by no mean I would intend that this > should be forbidden or wrong. Anyway, data sizes are growing all the > time: ram in computers, HDUs capacity, file sizes, DVDs (Blueray?) and > so on. I thought so because in your example there were 48K (do I > remember well?) to send, and I asked myself if those 48K could ever turn > to 480K, which could be even more "extreme"... I've said it at least three times now that I would not send any more than 512k in one gulp, despite today's technology and advancements. Heck, I would not send the standard RFC 3977 72 characters without a CRLF unless the remote server explicitly told me it was ok to send gigabytes terminated by a CRLF pair. > Ok, I have "sproloquied" (piggy italian-latin-english term for > "overtalking") enough. No, you have not over-talked. You have exposed some serious questions about the gambas philosophy. It is not OK for gambas to decide if the programmer might have done something wrong. It is only for the programmer to decide if he/she did something wrong. > > Best regards, and happy big-chunks-stuffing-in-hyperspace. lol ... too funny. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
