hla-stdlib-talk Mailing List for HLA Standard Library (Page 2)
Brought to you by:
evenbit
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
(5) |
Aug
(8) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
(3) |
Feb
(7) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(13) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Frank K. <fbk...@ve...> - 2008-02-15 09:21:32
|
Nathan Baker wrote: ... > > w.ReadFile( hStdIn, &InputBuffer, 1, InputIndex, 0 ); > > Who "InputIndex"? I'm thinking we want an address here (? remember I > don't do Windows). Perhaps that's what you've got... > > I cribbed InputBuffer and InputIndex from the original getc() -- again, > I am guessing they are defined in "../include/stdinunit.hhf" -- probably > need to call stdin.read() { the original calls readln() but that won't > work here }. Could that be a problem? Or an opportunity? ... > "Leaking handles" is a pretty bad problem. Other than that, it looks > good to me! > > I don't think so. To my understanding, the 'standard I/O' handles are > created (by the OS) for each process when it starts, and are closed > automatically when it terminates. The 'GetStdHandle' doesn't actually > create a new handle... it just asks the OS for the handle that was > already created when the process started. I think closing it > prematurely might be a bad thing. I'll check the book to make sure. Yeah... or see what GetStdHandle(-10) returns on repeated calls. > What I've got for Linux does a similar thing... we "get" a whole > bleedin' structure for "current mode" - but only clear two bits, and > "set" to that. It is not strictly "right". If the pesky user suspends > the program with control-z, and restarts it with "fg", we're back > reading one key... but waiting for "Enter" again! :( A similar problem > may occur if the window size is changed (in an Xterm). We could fix > that > by blocking control-c/control-z entirely - handling it ourselves, > perhaps. Or we can "catch" these signals and do the appropriate > cleanup/restoration of our "tweak". (I'm not sure how to do that one). > > Could you post the code? Or is it already at Linux-nasm-users? Might be... in the form of "Beth's Game". Here's a "simplified" version - as-is, needs-work! And a C program (since you like C compilers these days) which does something a little more - kills more "processing" and checks for control-c. The way he does "check-for-key" doesn't impress me. Rather than make the handle non-blocking, we can use sys__newselect for that. There are several interesting points: size of termios is not what I'm using (!), different tweak for Ubuntu (!), and the different bits in termios that he tweaks and I leave alone... Best, Frank begin Nasmcode; global _start ; misc. equates %define NL 10 %define STDIN 0 %define STDOUT 1 ; sys_calls %define SYS_EXIT 1 %define SYS_READ 3 %define SYS_WRITE 4 %define SYS_IOCTL 54 section .text _start: nop .top: call getc cmp al, 'q' jz exit call putc call showalhex mov al, 10 call putc jmp short .top exit: mov ebx, eax mov eax, 1 int 80h ;------------------- ;------------------ showalhex: push eax mov ah, al shr al, 4 cmp al, 0Ah sbb al, 69h das call putc mov al, ah and al, 0Fh cmp al, 0Ah sbb al, 69h das call putc pop eax ret ;----------------------- ;--------------------------- putc: push edx push ecx push ebx push eax mov eax, 4 mov ebx, 1 mov ecx, esp mov edx, 1 int 80h pop eax pop ebx pop ecx pop edx ret ;----------------------------- ;----------------------------- ; ioctl subfunctions %define TCGETS 0x5401 ; tty-"magic" %define TCSETS 0x5402 ; flags for 'em %define ICANON 2 ;.Do erase and kill processing. %define ECHO 8 ;.Enable echo. struc termios alignb 4 .c_iflag: resd 1 ; input mode flags .c_oflag: resd 1 ; output mode flags .c_cflag: resd 1 ; control mode flags .c_lflag: resd 1 ; local mode flags .c_line: resb 1 ; line discipline .c_cc: resb 19 ; control characters endstruc ;--------------------------------- getc: push ebp mov ebp, esp sub esp, termios_size ; make a place for current kbd mode push edx push ecx push ebx mov eax, SYS_IOCTL ; get current mode mov ebx, STDIN mov ecx, TCGETS lea edx, [ebp - termios_size] int 80h ; monkey with it and dword [ebp - termios_size + termios.c_lflag], ~(ICANON | ECHO) mov eax, SYS_IOCTL mov ebx, STDIN mov ecx, TCSETS lea edx, [ebp - termios_size] int 80h xor eax, eax push eax ; this is the buffer to read into mov eax, SYS_READ mov ebx, STDIN mov ecx, esp ; character goes on the stack mov edx, 1 ; just one int 80h ; do it ; restore normal kbd mode or dword [ebp - termios_size + termios.c_lflag], ICANON | ECHO mov eax, SYS_IOCTL mov ebx, STDIN mov ecx, TCSETS lea edx, [ebp - termios_size] int 80h pop eax ; get character into al pop ebx ; restore caller's regs pop ecx pop edx mov esp, ebp ; leave pop ebp ret ;------------------------- end Nasmcode; begin Ccode; /* *************************************************************************** * * Copyright 1992-2005 by Pete Wilson All Rights Reserved * 50 Staples Street : Lowell Massachusetts 01851 : USA * <a href="http://www.pwilson.net/">http://www.pwilson.net/</a> pete at pwilson dot net +1 978-454-4547 * * This item is free software: you can redistribute it and/or modify it as * long as you preserve this copyright notice. Pete Wilson prepared this item * hoping it might be useful, but it has NO WARRANTY WHATEVER, not even any * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * *************************************************************************** */ /* *************************************************************************** * * KBHIT.C * * Based on the work of W. Richard Stevens in "Advanced Programming in * the Unix Environment," Addison-Wesley; and of Floyd Davidson. * * Contains these functions: * * To set the TTY mode: * tty_set_raw() Unix setup to read a character at a time. * tty_set_cooked() Unix setup to reverse tty_set_raw() * * To read keyboard input: * kb_getc() keyboard get character, NON-BLOCKING. If a char * has been typed, return it. Else return 0. * kb_getc_w() kb get char with wait: BLOCKING. Wait for a char * to be typed and return it. * * How to use: * tty_set_raw() set the TTY mode to read one char at a time. * kb_getc() read chars one by one. * tty_set_cooked() VERY IMPORTANT: restore cooked mode when done. * * Revision History: * * DATE DESCRIPTION * ----------- -------------------------------------------- * 12-jan-2002 new * 20-aug-2002 cleanup * 24-nov-2003 Fixed kb_getc() so that it really is non blocking(JH) * 10-sep-2006 Let kb_getc() work right under certain Unix/Linux flavors * *************************************************************************** */ #ifdef __cplusplus extern "C" { #endif #include <stdio.h> #include <stdlib.h> #include <string.h> #include <termios.h> #include <unistd.h> #include <errno.h> #ifndef STDIN_FILENO #define STDIN_FILENO 0 #endif extern int errno; static struct termios termattr, save_termattr; static int ttysavefd = -1; static enum { RESET, RAW, CBREAK } ttystate = RESET; /* *************************************************************************** * * set_tty_raw(), put the user's TTY in one-character-at-a-time mode. * returns 0 on success, -1 on failure. * *************************************************************************** */ int set_tty_raw(void) { int i; i = tcgetattr (STDIN_FILENO, &termattr); if (i < 0) { printf("tcgetattr() returned %d for fildes=%d\n",i,STDIN_FILENO); perror (""); return -1; } save_termattr = termattr; termattr.c_lflag &= ~(ECHO | ICANON | IEXTEN | ISIG); termattr.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON); termattr.c_cflag &= ~(CSIZE | PARENB); termattr.c_cflag |= CS8; termattr.c_oflag &= ~(OPOST); termattr.c_cc[VMIN] = 1; /* or 0 for some Unices; <a href="#note1"> see note 1</a> */ termattr.c_cc[VTIME] = 0; i = tcsetattr (STDIN_FILENO, TCSANOW, &termattr); if (i < 0) { printf("tcsetattr() returned %d for fildes=%d\n",i,STDIN_FILENO); perror(""); return -1; } ttystate = RAW; ttysavefd = STDIN_FILENO; return 0; } /* *************************************************************************** * * set_tty_cbreak(), put the user's TTY in cbreak mode. * returns 0 on success, -1 on failure. * *************************************************************************** */ int set_tty_cbreak() { int i; i = tcgetattr (STDIN_FILENO, &termattr); if (i < 0) { printf("tcgetattr() returned %d for fildes=%d\n",i,STDIN_FILENO); perror (""); return -1; } save_termattr = termattr; termattr.c_lflag &= ~(ECHO | ICANON); termattr.c_cc[VMIN] = 1; termattr.c_cc[VTIME] = 0; i = tcsetattr (STDIN_FILENO, TCSANOW, &termattr); if (i < 0) { printf("tcsetattr() returned %d for fildes=%d\n",i,STDIN_FILENO); perror (""); return -1; } ttystate = CBREAK; ttysavefd = STDIN_FILENO; return 0; } /* *************************************************************************** * * set_tty_cooked(), restore normal TTY mode. Very important to call * the function before exiting else the TTY won't be too usable. * returns 0 on success, -1 on failure. * *************************************************************************** */ int set_tty_cooked() { int i; if (ttystate != CBREAK && ttystate != RAW) { return 0; } i = tcsetattr (STDIN_FILENO, TCSAFLUSH, &save_termattr); if (i < 0) { return -1; } ttystate = RESET; return 0; } /* *************************************************************************** * * kb_getc(), if there's a typed character waiting to be read, * return it; else return 0. * 10-sep-2006: kb_getc() fails (it hangs on the read() and never returns * until a char is typed) under some Unix/Linux versions: ubuntu, suse, and * maybe others. To make it work, please uncomment two source lines below. * *************************************************************************** */ unsigned char kb_getc(void) { int i; unsigned char ch; ssize_t size; /* termattr.c_cc[VMIN] = 0; */ /* uncomment if needed */ i = tcsetattr (STDIN_FILENO, TCSANOW, &termattr); size = read (STDIN_FILENO, &ch, 1); /* termattr.c_cc[VMIN] = 1; */ /* uncomment if needed */ i = tcsetattr (STDIN_FILENO, TCSANOW, &termattr); if (size == 0) { return 0; } else { return ch; } } /* *************************************************************************** * * kb_getc_w(), wait for a character to be typed and return it. * *************************************************************************** */ unsigned char kb_getc_w(void) { unsigned char ch; size_t size; while (1) { usleep(20000); /* 1/50th second: thanks, Floyd! */ size = read (STDIN_FILENO, &ch, 1); if (size > 0) { break; } } return ch; } #define TEST #ifdef TEST void echo(unsigned char ch); static enum { CH_ONLY, CH_HEX } how_echo = CH_ONLY; int main(int argc, char * argv[]) { unsigned char ch; printf("Test Unix single-character input.\n"); printf("termios size %d\n", sizeof(struct termios)); set_tty_raw(); /* set up character-at-a-time */ while (1) /* wait here for a typed char */ { usleep(20000); /* 1/50th second: thanks, Floyd! */ ch = kb_getc(); /* char typed by user? */ if (0x03 == ch) /* might be control-C */ { set_tty_cooked(); /* control-C, restore normal TTY mode */ return 1; /* and get out */ } echo(ch); /* not control-C, echo it */ } } void echo(unsigned char ch) { switch (how_echo) { case CH_HEX: printf("%c,0x%x ",ch,ch); break; default: case CH_ONLY: printf("%c", ch); break; } fflush(stdout); /* push it out */ } #endif /* test */ #ifdef __cplusplus } #endif end Ccode; :) |
From: Nathan B. <eve...@ya...> - 2008-02-15 05:51:06
|
Frank Kotler <fbk...@ve...> wrote: Nathan Baker wrote: > Just coded this real quick and haven't tested it, but this is close to > what a 'non-buffered' stdin.getc() function (for Windows) would look like: Okay... > unit StdInput; > #include( "../include/stdinunit.hhf" ) > > procedure nb_getc; > @nodisplay; > > var > hStdIn :dword; > curMode :dword; > newMode :dword; > > begin nb_getc; > > w.GetStdHandle( STD_INPUT_HANDLE ); > mov( eax, hStdIn ); You're opening a new stdin handle with every call of this puppy. "Herbert's version" of "Beth's game" checks to see if we've got an handle (which means it has to be initialized to zero), and if so, skips over acquiring a handle and "tweaking" it. Since you're "untweaking" it at the end, you'd only want to skip acquiring a new one. Well there is probably something like a global variable containing the handle... perhaps in the "../include/stdinunit.hhf" which is included in the above code. I haven't taken the time to look... just wanted to get the discussion started. IIRC, Randy asked questions about the issue many, many months ago. He ran into a problem with it on BSD, or something... I can't remember what the "show-stopper" was. I just think it is worth looking at again. > w.GetConsoleMode( hStdIn, curMode ); > mov( curMode, eax ); > and( #$F9, al ); HLA knows the names of the bits in question. Why not use 'em? I don't know how to say " ~(ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT)" in HLAese, but I think that's what you want. Yeah, good point! HLAese is simply prepending a "w." in front of those -- same goes for the STD_IN_HANDLE above. > mov( eax, newMode ); > w.SetConsoleMode( hStdIn, newMode ); > > w.ReadFile( hStdIn, &InputBuffer, 1, InputIndex, 0 ); Who "InputIndex"? I'm thinking we want an address here (? remember I don't do Windows). Perhaps that's what you've got... I cribbed InputBuffer and InputIndex from the original getc() -- again, I am guessing they are defined in "../include/stdinunit.hhf" -- probably need to call stdin.read() { the original calls readln() but that won't work here }. > w.SetConsoleMode( hStdIn, curMode ); > mov( InputBuffer[ 0 ], al ); > ret(); > > end nb_getc; "Leaking handles" is a pretty bad problem. Other than that, it looks good to me! I don't think so. To my understanding, the 'standard I/O' handles are created (by the OS) for each process when it starts, and are closed automatically when it terminates. The 'GetStdHandle' doesn't actually create a new handle... it just asks the OS for the handle that was already created when the process started. I think closing it prematurely might be a bad thing. I'll check the book to make sure. What I've got for Linux does a similar thing... we "get" a whole bleedin' structure for "current mode" - but only clear two bits, and "set" to that. It is not strictly "right". If the pesky user suspends the program with control-z, and restarts it with "fg", we're back reading one key... but waiting for "Enter" again! :( A similar problem may occur if the window size is changed (in an Xterm). We could fix that by blocking control-c/control-z entirely - handling it ourselves, perhaps. Or we can "catch" these signals and do the appropriate cleanup/restoration of our "tweak". (I'm not sure how to do that one). Could you post the code? Or is it already at Linux-nasm-users? Nathan. I'm fairly certain that this code is Linux-specific, and *won't* work with BSD... nor MacOSX, I imagine. I think they've got sys_ioctl, but I think "TCGETS" is Linux-specific. Dunno how they do it (and what issues we'd encounter). In any case - I agree that it's a nice thing to be able to do. Good start! Best, Frank ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Hla-stdlib-talk mailing list Hla...@li... https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. |
From: Frank K. <fbk...@ve...> - 2008-02-15 03:14:54
|
Nathan Baker wrote: > Just coded this real quick and haven't tested it, but this is close to > what a 'non-buffered' stdin.getc() function (for Windows) would look like: Okay... > unit StdInput; > #include( "../include/stdinunit.hhf" ) > > procedure nb_getc; > @nodisplay; > > var > hStdIn :dword; > curMode :dword; > newMode :dword; > > begin nb_getc; > > w.GetStdHandle( STD_INPUT_HANDLE ); > mov( eax, hStdIn ); You're opening a new stdin handle with every call of this puppy. "Herbert's version" of "Beth's game" checks to see if we've got an handle (which means it has to be initialized to zero), and if so, skips over acquiring a handle and "tweaking" it. Since you're "untweaking" it at the end, you'd only want to skip acquiring a new one. > w.GetConsoleMode( hStdIn, curMode ); > mov( curMode, eax ); > and( #$F9, al ); HLA knows the names of the bits in question. Why not use 'em? I don't know how to say " ~(ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT)" in HLAese, but I think that's what you want. > mov( eax, newMode ); > w.SetConsoleMode( hStdIn, newMode ); > > w.ReadFile( hStdIn, &InputBuffer, 1, InputIndex, 0 ); Who "InputIndex"? I'm thinking we want an address here (? remember I don't do Windows). Perhaps that's what you've got... > w.SetConsoleMode( hStdIn, curMode ); > mov( InputBuffer[ 0 ], al ); > ret(); > > end nb_getc; "Leaking handles" is a pretty bad problem. Other than that, it looks good to me! What I've got for Linux does a similar thing... we "get" a whole bleedin' structure for "current mode" - but only clear two bits, and "set" to that. It is not strictly "right". If the pesky user suspends the program with control-z, and restarts it with "fg", we're back reading one key... but waiting for "Enter" again! :( A similar problem may occur if the window size is changed (in an Xterm). We could fix that by blocking control-c/control-z entirely - handling it ourselves, perhaps. Or we can "catch" these signals and do the appropriate cleanup/restoration of our "tweak". (I'm not sure how to do that one). I'm fairly certain that this code is Linux-specific, and *won't* work with BSD... nor MacOSX, I imagine. I think they've got sys_ioctl, but I think "TCGETS" is Linux-specific. Dunno how they do it (and what issues we'd encounter). In any case - I agree that it's a nice thing to be able to do. Good start! Best, Frank |
From: Nathan B. <eve...@ya...> - 2008-02-15 01:59:56
|
Just coded this real quick and haven't tested it, but this is close to what a 'non-buffered' stdin.getc() function (for Windows) would look like: unit StdInput; #include( "../include/stdinunit.hhf" ) procedure nb_getc; @nodisplay; var hStdIn :dword; curMode :dword; newMode :dword; begin nb_getc; w.GetStdHandle( STD_INPUT_HANDLE ); mov( eax, hStdIn ); w.GetConsoleMode( hStdIn, curMode ); mov( curMode, eax ); and( #$F9, al ); mov( eax, newMode ); w.SetConsoleMode( hStdIn, newMode ); w.ReadFile( hStdIn, &InputBuffer, 1, InputIndex, 0 ); w.SetConsoleMode( hStdIn, curMode ); mov( InputBuffer[ 0 ], al ); ret(); end nb_getc; Nathan. end StdInput; --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. |
From: Nathan B. <eve...@ya...> - 2008-02-07 03:17:20
|
I have started the beginnings of a Wiki for the Standard Library project at SourceForge: http://hla-stdlib.wiki.sourceforge.net/ I'm guessing the best use of the wiki would be to give a brief introduction to some of the functions in each library module and demonstrate their use with a little bit of example code. Sort-of like brief tutorials. If anyone has any other ideas of what would be useful to help in the transition to the new library, let me know. Also, if anyone wants to create the webpage (hosted by SF), then let me know (the other dude ran-off). Nathan. --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. |
From: Nathan B. <eve...@ya...> - 2008-01-30 20:18:31
|
Okay, just the filenames. Cool beans! The subject line had me thinking of "stdout.stdout_puts()" type of nightmares. Nathan. Nathan Baker <eve...@ya...> wrote: Point of clarification: Are you talking about the 'filenames' being prefixed? or the actual name of the functions being prefixed? Nathan. Randall Hyde <ran...@ea...> wrote: Hi All, I just updated the sourceforge repository. I've changed all the names of the string functions to have a "str_" prefix. This is being done to avoid "name pollution" in the object modules namespace of the stdlib.lib/stdlib.a file (the linker complains if you have two .obj or two .o files with the same name, even if they are different objects). Eventually, all the stdlib filenames will adhere to the convention of having some prefix that specifies the module. hLater, Randy Hyde ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Hla-stdlib-talk mailing list Hla...@li... https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search.------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ Hla-stdlib-talk mailing list Hla...@li... https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk --------------------------------- Never miss a thing. Make Yahoo your homepage. |
From: Nathan B. <eve...@ya...> - 2008-01-30 02:20:50
|
Point of clarification: Are you talking about the 'filenames' being prefixed? or the actual name of the functions being prefixed? Nathan. Randall Hyde <ran...@ea...> wrote: Hi All, I just updated the sourceforge repository. I've changed all the names of the string functions to have a "str_" prefix. This is being done to avoid "name pollution" in the object modules namespace of the stdlib.lib/stdlib.a file (the linker complains if you have two .obj or two .o files with the same name, even if they are different objects). Eventually, all the stdlib filenames will adhere to the convention of having some prefix that specifies the module. hLater, Randy Hyde ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Hla-stdlib-talk mailing list Hla...@li... https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. |
From: Randall H. <ran...@ea...> - 2008-01-30 01:44:15
|
Hi All, I just updated the sourceforge repository. I've changed all the names of the string functions to have a "str_" prefix. This is being done to avoid "name pollution" in the object modules namespace of the stdlib.lib/stdlib.a file (the linker complains if you have two .obj or two .o files with the same name, even if they are different objects). Eventually, all the stdlib filenames will adhere to the convention of having some prefix that specifies the module. hLater, Randy Hyde |
From: Nathan B. <eve...@ya...> - 2007-09-21 00:41:30
|
rh...@cs... wrote: > http://sourceforge.net/project/showfiles.php?group_id=165727 > > Nathan. I ought to be registered as a developer on this site. :-) Oh, yeah, I will change that. hLater, Randy Hyde ran...@ea..., btw. For this list? I think you might need to change that yourself: https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk I think I might have a different one listed at Freshmeat. Yeah, I updated that listing and forgot about it being LiUnix-only. Guess whoever "manned-the-wheel" this morning didn't notice because they approved the update: http://freshmeat.net/releases/262135/ I'll try to attach an explanatory note when I update the e-mail. Nathan. --------------------------------- Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! |
From: <rh...@cs...> - 2007-09-20 15:22:25
|
> http://sourceforge.net/project/showfiles.php?group_id=165727 > > Nathan. I ought to be registered as a developer on this site. :-) hLater, Randy Hyde ran...@ea..., btw. |
From: Nathan B. <eve...@ya...> - 2007-09-20 04:05:51
|
http://sourceforge.net/project/showfiles.php?group_id=165727 Nathan. --------------------------------- Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search. |
From: Frank K. <fbk...@ve...> - 2007-09-20 01:47:59
|
Nathan Baker wrote: > > > */Frank Kotler <fbk...@ve...>/* wrote: > > Nathan Baker wrote: > > If someone wants to assist by sending that large library Zip (and > those > > two document zips) to SF "using *anonymous* FTP to > > *upload.sourceforge.net* in the *incoming* directory" then I can > "slide > > them into place". > > Okay. Doing the "release" fol-de-rol, you should find 'em in the > list. I > left 'em as "hlalibsrc2.zip", "html.zip", and "rtf.zip". You may wish, > someday, that they had version numbers with 'em... > > Okay, it seems that I didn't "arrive" in time and the files have "rolled > off" the list (I thought they were suppose to remain for at least 24 > hours -- apparently not). Could I bother you to send them again? I > will be checking-back all night. Or perhaps we find a better idea? Okay, done. Just did a "release" of Nasm 0.99.03... Saw your files on "the list", so it appears to have worked. The rigamarole doesn't seem as bad, once you get used to it. Or maybe SF was just going kinda quick, today... > Be aware, if you're not, that you'll have to "save changes" after every > stinkin' step, before it'll "take". In particular, after you've added > the files from the "list" (which takes 'em off the list), although it > shows multiple files on one page, you have to set "type" and "platform" > one-by-one. > > Okay, thanks for the tip. Another thought... if you've got "release notes" and "changelog" prepared as files, you can "browse" for 'em, instead of having to type 'em in... I just type in whatever comes to mind, which isn't so great. No "trick" to uploading those files. Just "ftp", "open upload.sf.net", "anonymous", <enter> for the password, "cd incoming", and "put" what you "got". "close" if you wanna be polite, and "bye". Slow upload - painful if you've got a slow connection. I'm glad to do it... Don't tell Betov. :) Best, Frank |
From: Frank K. <fbk...@ve...> - 2007-09-19 09:43:31
|
Nathan Baker wrote: > If someone wants to assist by sending that large library Zip (and those > two document zips) to SF "using *anonymous* FTP to > *upload.sourceforge.net* in the *incoming* directory" then I can "slide > them into place". Okay. Doing the "release" fol-de-rol, you should find 'em in the list. I left 'em as "hlalibsrc2.zip", "html.zip", and "rtf.zip". You may wish, someday, that they had version numbers with 'em... Be aware, if you're not, that you'll have to "save changes" after every stinkin' step, before it'll "take". In particular, after you've added the files from the "list" (which takes 'em off the list), although it shows multiple files on one page, you have to set "type" and "platform" one-by-one. Thanks, Nathan! Best, Frank |
From: Nathan B. <eve...@ya...> - 2007-09-19 07:49:56
|
If someone wants to assist by sending that large library Zip (and those two document zips) to SF "using anonymous FTP to upload.sourceforge.net in the incoming directory" then I can "slide them into place". --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! |
From: Nathan B. <eve...@ya...> - 2007-07-24 01:32:19
|
rh...@cs... wrote: > rh...@cs... wrote: > >>I'm wondering if anyone is reading this list anymore? >>Cheers, >>Randy Hyde >> >> > > No - not much to read. :) > > Best, > Frank Well,.... The reason I ask is that as HLA stdlib v2.x begins reaching critical mass, I feel that this is the place to start posting announcements. As good as any. If the list doesn't get used, we might as well delete it. In particular, it would be cool to get some extra test functions written, if anyone is interested in participating. I can probably write some of these. Also, I'm currently working on string functions, so now is the time to start yelling about what string functions ought to be in the library. Then again, if it's just the two of us, I probably should just keep it in the AoA/HLA Yahoo group. It has been a while, perhaps the new folk don't know about this, so I will cross-post. http://sourceforge.net/projects/hla-stdlib/ hLater, Randy Hyde ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Hla-stdlib-talk mailing list Hla...@li... https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk --------------------------------- Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. |
From: Nathan B. <eve...@ya...> - 2007-07-24 00:37:59
|
SF is showing these subscribers: --- START --- ab...@ya... eve...@ya... fbk...@co... gab...@ya... rh...@cs... te...@co... t....@mi... --- END --- Total subscriber count: 7 Frank Kotler <fbk...@co...> wrote: rh...@cs... wrote: >I'm wondering if anyone is reading this list anymore? >Cheers, >Randy Hyde > > No - not much to read. :) Best, Frank ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Hla-stdlib-talk mailing list Hla...@li... https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk --------------------------------- Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. |
From: <rh...@cs...> - 2007-07-23 22:37:16
|
> rh...@cs... wrote: > >>I'm wondering if anyone is reading this list anymore? >>Cheers, >>Randy Hyde >> >> > > No - not much to read. :) > > Best, > Frank Well,.... The reason I ask is that as HLA stdlib v2.x begins reaching critical mass, I feel that this is the place to start posting announcements. In particular, it would be cool to get some extra test functions written, if anyone is interested in participating. Also, I'm currently working on string functions, so now is the time to start yelling about what string functions ought to be in the library. Then again, if it's just the two of us, I probably should just keep it in the AoA/HLA Yahoo group. hLater, Randy Hyde |
From: Frank K. <fbk...@co...> - 2007-07-23 06:56:34
|
rh...@cs... wrote: >I'm wondering if anyone is reading this list anymore? >Cheers, >Randy Hyde > > No - not much to read. :) Best, Frank |
From: <rh...@cs...> - 2007-07-19 20:02:21
|
I'm wondering if anyone is reading this list anymore? Cheers, Randy Hyde > For those joining, here is a complete list of project roles. Just let me > know what role, tasks, and duties you are interested in taking on so that > I can set up your membership/permissions accordingly. > > Developer > Project Manager > Unix Admin > Doc Writer > Tester > Support Manager > Graphic/Other Designer > DBA (Database Administrator) > Editorial/Content Writer > Packager (.rpm, .deb etc) > Analysis / Design > Advisor/Mentor/Consultant > Distributor/Promoter > Content Management > Requirements Engineering > Web Designer > Porter (Cross Platform Devel.) > Undefined > All-hands Person > No specific role > > > Nathan. > > > > --------------------------------- > Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! > Messenger with Voice. |
From: <rh...@cs...> - 2006-11-15 02:13:24
|
> Nathan Baker wrote: >> Randy, >> >> Are there any "released to the public domain" notices in your HLA StdL= ib >> source Zips? At first glance, I don't see any. > > I think they've been added in the "new" versions - the stuff Randy's > been posting for testing has got 'em. (pity we haven't got an "open for > prepend" :) Yup, they are standard text in the HLA stdlib v2.0 code I'm readying righ= t now. I'll probably post v2.0 (stdin, stdout, stderr, fileio, and conv modules) within a few weeks. I still have some test code to write and documentation to organize, but the main code is basically complete for these modules. Cheers, Randy Hyde |
From: Frank K. <fbk...@co...> - 2006-11-13 23:30:51
|
Nathan Baker wrote: > Randy, > > Are there any "released to the public domain" notices in your HLA StdLib > source Zips? At first glance, I don't see any. I think they've been added in the "new" versions - the stuff Randy's been posting for testing has got 'em. (pity we haven't got an "open for prepend" :) Best, Frank |
From: Nathan B. <eve...@ya...> - 2006-11-13 21:02:29
|
Randy, Are there any "released to the public domain" notices in your HLA StdLib source Zips? At first glance, I don't see any. Nathan. --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. |
From: <rh...@cs...> - 2006-08-05 22:38:10
|
> 1) sign-up for a SF account > 2) give either me or Sevag your account name so we can add you to the > project rhydehla Cheers, Randy Hyde |
From: Nathan B. <eve...@ya...> - 2006-08-05 20:09:51
|
1) sign-up for a SF account 2) give either me or Sevag your account name so we can add you to the project 3) the instructions for subversion are on this page: http://sourceforge.net/docs/E09 Subversion Server: https://svn.sourceforge.net Path to Repository: /svnroot/hla-stdlib Connection Information The following configuration settings are used to access a SourceForge.net-hosted SVN repository: * Hostname: svn.sourceforge.net * Port: 443 * Protocol: HTTPS * Repository Path: /svnroot/PROJECTNAME (PROJECTNAME is the project's UNIX name) * Username: Your SourceForge.net username for SVN write operations, none will be requested otherwise. * Password: Your SourceForge.net user password for write operations, none will be requested otherwise. If you receive a 403 Forbidden error, either your password doesn't match (it could be a sync issue, try changing your password and attempting to access the service a few minutes later with the new password) or your project administrator hasn't granted you SVN write permissions (if you are the project admin, you must still grant yourself that permission). Go to the members section of your project admin pages to set this option. Firewalls and proxy servers may present a problem in using SVN. No workarounds are provided as HTTPS should be passed without modification from almost all ISPs world-wide. Should a firewall or proxy be causing issues with your connection, contact your network administrator or ISP for further assistance. rh...@cs... wrote: Someone needs to explain to me how to use SourceForge (which I haven't touched in about 3-4 years). I read that it supports SVN/Tortoise, which is great as that is the source code control system I use to maintain HLA and the HLA stdlib, but I don't have a clue how to connect my client up to SourceForge. I'm a bit busy right now making changes to the stdlib to prepare it for uploading to SourceForge, so if someone has a few minutes to figure out what I need to know, that would be a big help. BTW, those who want to be able to work in the source tree ought to get SVN/Tortoise. It's really an awesome SCC system. Cheers, Randy Hyde ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Hla-stdlib-talk mailing list Hla...@li... https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. |
From: <rh...@cs...> - 2006-08-05 16:56:04
|
Someone needs to explain to me how to use SourceForge (which I haven't touched in about 3-4 years). I read that it supports SVN/Tortoise, which is great as that is the source code control system I use to maintain HLA and the HLA stdlib, but I don't have a clue how to connect my client up to SourceForge. I'm a bit busy right now making changes to the stdlib to prepare it for uploading to SourceForge, so if someone has a few minutes to figure out what I need to know, that would be a big help. BTW, those who want to be able to work in the source tree ought to get SVN/Tortoise. It's really an awesome SCC system. Cheers, Randy Hyde |