Re: Buggy post url cmd - socket stays open
Hi Alain, Try this witch works for me perfectly from MC 2.32 to 2.5: set httpheaders to Content-type: application/x-www-form-urlencoded return post fld 1 to url myURL Hope this help. Best, On Thu, 2003-07-24 at 05:19, Alain Farmer wrote: Hello Scott and y'all, I have a persistant problem with the post url syntax of MetaCard 2.5, as I did with 2.4 as well. The client is a MetaCard 2.5 stack with the following handler in a button : on mouseUp put http://www.giguere.uqam.ca/; into myHost put myHost XA/MenusXApost.cgi into myURL if the openSockets is empty then post field 1 to url myURL if the result is not empty then answer the result else answer it else beep end if end mouseUp The CGI program on the server-side is a HyperCard-based CGI which performs marvelously. It returns the minimum set of HTTP headers required by MetaCard. The proof of this is that the first click on the above button indeed returns what it is supposed to. Btw, I am using Webstar 2.1 on MacOS 8.6 on the server-side. The problem arises after the first click of this button. On the second and subsequent clicks of this button, the handler beeps, e.g. the openSockets is not empty which, IOW, means that the socket remains open after the first click. In fact, it (the socket) *never* closes, and this inhibits it from doing its thing more than once. My diagnostic, therefore, is that there is a bug in MC's post command whereby the socket that is opened is never closed. Please fix this *bug* by making the socket close automatically ASAP after the reply is received by the MC client. Or give us the new syntax we need to *close* the open sockets ourselves. If you disbelieve my account, then feel free to download a copy of my client stack which exhibits this problem : http://ufp.uqam.ca/MC/test_url_stuff.mc.zip Thank you for your time and earnest work, :) Alain Farmer NB: This is relatively URGENT for me. Please respond as soon as you can [Scott]. It has nothing to do with the interface; this is clearly an engine issue. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard -- Bien cordialement, Pierre Sahores Serveurs d'applications bases ACID SQL Penser et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Standalone Builder question
Thank you all for your kind answers and wise recommendations to test the standalone on a Windoze machine before releasing it. But actually the reason why I decided to build the Win standalone on a Mac is because I'm facing another problem : a Win standalone built on an XP machine doesn't launch on a Win98 machine... Actually it's been built on an XP machine, then burned on a CD, then ftp transfered via Fetch on a Mac to my client who can't launch it after downloading it to his PC... We've done that before and it worked fine, the only difference is that there were Win98 machines on both sides... Did anyone experience anything similar ? I guess something gets lost on the way, but I can't figure out when... I thought that building the Win app on Mac might reduce the risks to spoil the file... Of course I still have the option to snail mail a CD... Thanks, JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
MC OpenGL (update)
Hi list, Although I don't have much time to spend on this project these days, I managed to build an external for accessing openGL on Mac. Since it's Carbon compatible, it should run on OS8.6 to OSX (haven't tested it on OSX though). As I already achieved something similar on Win32 a few months ago, some sort of cross-platform compatibility already exists. Nevertheless, I'm still puzzled about the way to implement openGL in a MC context. So far, I see 3 options : 1) implement all openGL functions in MetaTalk. I see several flaws in this option : - there are more than 130 functions, which might end up in a HUGE external. - accessing openGL would still remain complicated, as programmers would still need to think code simultaneously in MT, C and openGL... - execution of scripts would be quite slow due to the multiple calls - some programing tricks tips in C + openGL would be impossible to reproduce... 2) make a selection of a limited number of openGL functions options, and implement them in a MetaTalk-compatible way. In that case, programmers would still think code in MT, and translation of the code to openGL would be completely transparent. Again several flaws : - how to do the selection of openGL functions ? - execution of scripts would be quite slow due to the multiple calls - some programing tricks tips in C + openGL would be impossible to reproduce... 3) keep doing what I've done in my experiments so far : build a different external for each project involving openGL. Each external features only the C functions (and openGL calls) to be used in each specific project. This option has several advantages : - the size of the external remains small - many programing tips can be used - scripts execution (and openGL calls) are done at high speed. OTOH the main drawback is that a specific C development needs to be done for each project. Of course, reusability of large portions of code is possible, but still : more programing debugging are necessary... Actually, if implementation of openGL in MC is quite feasable, it's not as straightforward as QT for instance... I would gladly apreciate any suggestion / discussion on this topic. According to previous reactions, I know that several list members (especially those involved in games and / or scientific apps) are highly interested in that option. Last but not least : there's a 4th option. As the company I'm working for isn't doing very well and as I might get laid off within the next few weeks, I can sell my skills as programer to those interested in developping projects including 3D imagery... I know it sounds like an heresy to fans of open source and those who think this list should remain a place to share code, but I guess I'll still have some monthly bills to pay, even after I get laid off... Thanks, JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Standalone Builder question
But actually the reason why I decided to build the Win standalone on a Mac is because I'm facing another problem : a Win standalone built on an XP machine doesn't launch on a Win98 machine... Actually it's been built on an XP machine, then burned on a CD, then ftp transfered via Fetch on a Mac to my client who can't launch it after downloading it to his PC... We've done that before and it worked fine, the only difference is that there were Win98 machines on both sides... Did anyone experience anything similar ? I guess something gets lost on the way, but I can't figure out when... I thought that building the Win app on Mac might reduce the risks to spoil the file... Of course I still have the option to snail mail a CD... Thanks, JB JB, I've had a problem with Win files, that I compile them, zip them, move them to a Win machine via network, and WinZip will not open them. I've not had a chance to test this, but I was told that if the stack/standalone has a resource fork (which mine do), it will ball up the works on Windows as far as zipping/unzipping. And that the fix is to strip the resource fork before zipping. Not just delete the contents, but remove the fork. I don't know if yours simply won't launch, or if it won't unzip, but just sharing another Mac-to-Win gotcha that bit me. Shari C -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Buggy post url cmd - socket stays open
At 8:19 pm -0700 23/7/03, Alain Farmer wrote: Hello Scott and y'all, I have a persistant problem with the post url syntax of MetaCard 2.5, as I did with 2.4 as well. The client is a MetaCard 2.5 stack with the following handler in a button : on mouseUp put http://www.giguere.uqam.ca/; into myHost put myHost XA/MenusXApost.cgi into myURL if the openSockets is empty then post field 1 to url myURL if the result is not empty then answer the result else answer it else beep end if end mouseUp The CGI program on the server-side is a HyperCard-based CGI which performs marvelously. It returns the minimum set of HTTP headers required by MetaCard. The proof of this is that the first click on the above button indeed returns what it is supposed to. Btw, I am using Webstar 2.1 on MacOS 8.6 on the server-side. The problem arises after the first click of this button. On the second and subsequent clicks of this button, the handler beeps, e.g. the openSockets is not empty which, IOW, means that the socket remains open after the first click. In fact, it (the socket) *never* closes, and this inhibits it from doing its thing more than once. My diagnostic, therefore, is that there is a bug in MC's post command whereby the socket that is opened is never closed. Please fix this *bug* by making the socket close automatically ASAP after the reply is received by the MC client. Or give us the new syntax we need to *close* the open sockets ourselves. If you disbelieve my account, then feel free to download a copy of my client stack which exhibits this problem : I believe you. But the behavior is intentional. By default, the libUrl script doesn't close the socket after completing a request. This allows re-use of the same socket which is useful if you are making a series of requests to the same server, and is in line with the HTTP 1.1 spec. (The socket will eventually get closed by the server.) Is there any reason that you need to check that the openSockets is empty? If it's just to prevent someone clicking on the button again while the request is being handled, you could disable the button at the top of the script and re-enable it after the request has completed. But if you really want to have the socket closed after the post competes, then the proper way would be to set the httpHeaders as follows: set the httpHeaders to Connection: close If you do this, the server should immediately close the socket after completing the post request (assuming the server is HTTP 1.1 compliant -- I don't know about Webstar 2.1) Cheers Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
launching apps in background
Hi list, I have a problem launching an application (Win 98 environment) in the background using the shell function: if I use: get shell(C:\volume\folder\app.exe) nothing happens using, launch(C:\volume\folder\app.exe) the application is launched but in the foreground... any suggestions? TIA Slavko Milekic - Slavko Milekic, M.D., Ph.D. Assoc. Prof. of Cognitive Science Digital Design Dept. of Art Education Art Therapy The University of the Arts 320 S. Broad St., Philadelphia, PA 19102 tel: 215-717-6052 // fax: 775-521-0930 // [EMAIL PROTECTED] www.uarts.edu/faculty/smilekic - ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Buggy post url cmd - socket stays open
Hello, Hi Alain, Try this witch works for me perfectly from MC 2.32 to 2.5: set httpheaders to Content-type: application/x-www-form-urlencoded return post fld 1 to url myURL Hope this help. Thank you for the attempt, Pierre, but I tried it just now and my problem remains unchanged. My client stack is running on top of MacOS 8.6 ; do you have the same setup as me? Perhaps this socket bug only affects those using the classic MacOS, or perhaps just a bug in versions of MacOS less than 9.x ... Any further ideas? Distressed, Alain __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Buggy post url cmd - socket stays open
FWIW, since this is in fact part of libURL, it is possible to edit the scripts in question and change their behavior if either the need is urgent or it doesn't get officially changed. If you truly want the socket immediately closed, is there any reason why you can't check for it and close it yourself after the transfer is complete? i.e. repeat until the openSockets is empty close socket (line 1 of the openSockets) end repeat HTH, Brian I believe you. But the behavior is intentional. By default, the libUrl script doesn't close the socket after completing a request. This allows re-use of the same socket which is useful if you are making a series of requests to the same server, and is in line with the HTTP 1.1 spec. (The socket will eventually get closed by the server.) -- Brian Yennie Chief Technology Officer QLD Learning, LLC www.QLDLearning.com PH: (904)-997-0212 EMAIL: [EMAIL PROTECTED] ---
Re: Buggy post url cmd - socket stays open
Bravo Yennie, you're a genius! :)) repeat until the openSockets is empty close socket (line 1 of the openSockets) end repeat The above makes it work. I am thrilled! :)) The close socket syntax is not documented anywhere. Or perhaps it is only my Help stacks that are too dated. Is it possible that my Help stacks were not upgraded to 2.5 along with the engine? Is this a 'separate' step? Thanks to y'all three for helping me so. Bonus points go to Yennie for actually solving the problem. What would I do without you MC veterans! This list is essential. :)) Regards, Alain __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Buggy post url cmd - socket stays open
On Thu, 2003-07-24 at 22:18, Alain Farmer wrote: Hello, Hi Alain, Try this witch works for me perfectly from MC 2.32 to 2.5: set httpheaders to Content-type: application/x-www-form-urlencoded return post fld 1 to url myURL Hope this help. Thank you for the attempt, Pierre, but I tried it just now and my problem remains unchanged. My client stack is running on top of MacOS 8.6 ; do you have the same setup as me? Perhaps this socket bug only affects those using the classic MacOS, or perhaps just a bug in versions of MacOS less than 9.x ... Any further ideas? Distressed, Alain __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Hi Alain, I don't use MacOS 8+Webstar+HC since 1999 and the up-on config is only used on the linux and jaguar platforms (+Apache+PHP+MC+PostgreSQL). You will probably get a best luck in listening to the Dave's and Brians advices. -- Bests, Pierre Sahores Serveurs d'applications bases ACID SQL Penser et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Buggy post url cmd - socket stays open
Alain, Glad it worked. "close socket" is documented under the "close" command, although a bit buried and sparse. You'll find it on the very last line of both the syntax listing and the help text. FWIW, the Rev documentation is more complete on this particular command- I often find it helpful to have both sets of docs on hand. Happy post-ing -- Brian Yennie Chief Technology Officer QLD Learning, LLC www.QLDLearning.com PH: (904)-997-0212 EMAIL: [EMAIL PROTECTED] ---
RE: launching apps in background
Slavo, You can't use a full path with shell() since it doesn't work on the command line either. You need to cd to the folder where the app is and then execute it using: get shell(cd C:\volume\folder start app.exe) If you have spaces in the path name or the app you'll have to quote them (be careful of the that needs to be passed to shell), as in: get shell(cd quote c:\program files\myapp quote start myapp.exe) I like to use variables instead: put quote c:\program files\myapp quote into tFolder get shell(cd tFolder start myapp.exe) Hope this helps, Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of slavko milekic Sent: Thursday, July 24, 2003 12:01 AM To: [EMAIL PROTECTED] Subject: launching apps in background Hi list, I have a problem launching an application (Win 98 environment) in the background using the shell function: if I use: get shell(C:\volume\folder\app.exe) nothing happens using, launch(C:\volume\folder\app.exe) the application is launched but in the foreground... any suggestions? TIA Slavko Milekic - Slavko Milekic, M.D., Ph.D. Assoc. Prof. of Cognitive Science Digital Design Dept. of Art Education Art Therapy The University of the Arts 320 S. Broad St., Philadelphia, PA 19102 tel: 215-717-6052 // fax: 775-521-0930 // [EMAIL PROTECTED] www.uarts.edu/faculty/smilekic - ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metac ard ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
