From s-lang at ottolander.nl Wed Feb 1 16:54:06 2006 From: s-lang at ottolander.nl (Leonard den Ottolander) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] Bug in slang 2.0.5 In-Reply-To: <200601031628.41017.nadvornik@suse.cz> References: <200511301831.46348.nadvornik@suse.cz> <200601031628.41017.nadvornik@suse.cz> Message-ID: <1138830846.2485.39.camel@athlon> Hi, On Tue, 2006-01-03 at 16:28 +0100, Vladimir Nadvornik wrote: > On Wednesday 30 November 2005 18:31, Vladimir Nadvornik wrote: > > There is a bug in slang 2.0.5 which causes that in utf8 mode a > > non-ascii character can't be printed to bottom right corner. > > The problem is in function write_string_with_care, which counts > > bytes and not characters. > > > > Here is a patch. Haven't seen any comment on this patch. Has it been committed? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From davis at space.mit.edu Wed Feb 1 17:15:54 2006 From: davis at space.mit.edu (John E. Davis) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] Bug in slang 2.0.5 In-Reply-To: <1138830846.2485.39.camel@athlon> References: <200511301831.46348.nadvornik@suse.cz> <200601031628.41017.nadvornik@suse.cz> <1138830846.2485.39.camel@athlon> Message-ID: <200602012215.k11MFs0Q005672@aluche.mit.edu> Leonard den Ottolander wrote: >Haven't seen any comment on this patch. Has it been committed? Yes, it will appear in 2.0.6. Changes since 2.0.5 [...] 8. src/sldisply.c: Writing a multi-byte character to the lower-right corner of terminals with automatic margins was not working (Vladimir Nadvornik nadvornik at suse, cz). --John From davis at space.mit.edu Sun Feb 5 17:33:38 2006 From: davis at space.mit.edu (John E. Davis) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] slang 2.0.6 released Message-ID: <200602052233.k15MXcDu026512@aluche.mit.edu> Version 2.0.6 has been released--- it is primarily a bug-fix release. See for download options. Here are the relevant MD5 sums: efed417548c1c6bd7ff8cbf0165103df 2.0.5__2.0.6.diff.bz2 e87d632be3c618cbe3826ca9d08db46a 2.0.5__2.0.6.diff.bz2.sig 3a44ef4ccd557ba527c74aca0a9df9c9 2.0.5__2.0.6.diff.gz 37ce724df3f9365dbed726e4bcf58fd4 2.0.5__2.0.6.diff.gz.sig efb055000636f312d5c3de56f3c70d12 slang-2.0.6.tar.bz2 1214405732547eb641d78794316e4235 slang-2.0.6.tar.bz2.sig fb8ab2dfc3d8f44b9161b9b0e0c94141 slang-2.0.6.tar.gz fe751335066708642fd66385cc4e8985 slang-2.0.6.tar.gz.sig Enjoy. --John Changes since 2.0.5 1. src/slmath.c: nint was returning the wrong value for numbers 0.5<=x<1. 2. src/slarrfuns.c: sum(Double_Type[0,0],1) was generating an access error. 3. src/*.c: Removed some unused variables. 4. src/slcommon.c: '=' instead of '==' was being used in the utf8_enable function. 5. doc/tm/*.tm: corrected some documentation typos (Nelson Beebe, beebe at math, utah, edu). 7. src/sltime.c: times function was returning a structure containing incorrect values (cstawarz at head, cfa, harvard, edu). 8. src/sldisply.c: Writing a multi-byte character to the lower-right corner of terminals with automatic margins was not working (Vladimir Nadvornik nadvornik at suse, cz). 9. src/slwclut.c: Allow \\^ in character set specifications to represent a literal '^'. See the documentation for strtrans for more information. 10. src/slcommon.c: Some systems that have nl_langinfo do not have CODESET. The configure script now checks for both. 11. autoconf/Makefile.in: Added ".PHONY" and "check" targets. 12. src/slstrops.c: "%c" in an sprintf style format descriptor made to work with wide-character arguments. It is nolonger necessary to use "%lc". 13. src/slmisc.c: Semantics of "\x{...}" changed to be more useful when the interpreter is running in non-UTF8 mode. Previously, "\x{...}" always expanded to a UTF-8 encoded string, regardless of the UTF-8 mode. Now, in non-UTF8 mode, \x{...} will expand to a UTF-8 encoded string when "..." consists of 3 or more characters, and for less than 2 characters, it specifies a byte. The behavior in UTF-8 mode has not changed: \x{...} always returns a UTF-8 encoded string. The upshot is that "\x{FF}" will produce the byte 0xFF when not in UTF-8 mode, and the 2 byte UTF-8 encoding when run in UTF-8 mode. "\x{FFF}" will expand to the apropriate UTF-8 encoding regardless of the mode. Note that the behavior of the non-brace form such as \xAB has not changed--- the result is still a single byte 0xAB. 14. src/slmisc.c: \u{...} may be used in string literals to specify a unicode character, regardless of the UTF-8 mode (on or off). Previously, \x{...} had this behavior. (See #13). 15. src/test: Tests are run in both UTF-8 and non-UTF-8 modes. 16. src/slvideo.c: djgpp version of write_attributes was broken (Gisle Vanem giva at bgnett, no) 17. slsh/readline.c: Call SLang_handle_interrupt if a read was interrupted by a signal. This will ensure that signal handlers will execute at the prompt. 18. src/sldisply.c: Added a check for buffer-overflow by tgetstr on TERMCAP based systems. 19. autoconf/: Updated config.sub and config.guess 20. slsh/readline.c: Added slsh_readline_noecho function. Also, strip trailing newline from string returned by slsh_readline* when in --no-readline mode. From ben at versaccounting.com Tue Feb 7 20:11:56 2006 From: ben at versaccounting.com (Ben Duncan) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] Database Opinons wanted ... Message-ID: <43E9455C.2010500@versaccounting.com> Those who know how to write B+Trees/DBM or got a good general idea of database operations Tell me what you think of this one ? http://www.coyotegulch.com/products/itzam/index.html Thanks ... -- Ben Duncan - VersAccounting Software LLC 336 Elton Road Jackson MS, 39212 "Never attribute to malice, that which can be adequately explained by stupidity" - Hanlon's Razor From p.boekholt at hetnet.nl Wed Feb 8 10:39:16 2006 From: p.boekholt at hetnet.nl (Paul Boekholt) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] Database Opinons wanted ... In-Reply-To: <43E9455C.2010500@versaccounting.com> Message-ID: <1F6rPY-0E0-00@earth.cosmos.com> On Tue, 07 Feb 2006 19:11:56 -0600, Ben Duncan said: > Those who know how to write B+Trees/DBM or got a > good general idea of database operations > Tell me what you think of this one ? > http://www.coyotegulch.com/products/itzam/index.html I've downloaded it and have a made an embryonic slang module for it, which you can find at http://www.cheesit.com/downloadfiles/slang/itzam.tgz It's a rather low level library, and the documentation isn't too well edited - what to think of itzam_btree_iterator_move_next Move to the previous record in sequence. If the position is at the beginning of the list, it returns ITZAM_AT_END. ... Return Value ITZAM_OKAY if the function succeeded ITZAM_AT_BEGIN if the iterator is already at the end of the list ITZAM_UNKNOWN the function failed; datafile is in an unknown state Anyway, I think this could be used to make a kind of MV database module, maybe I'll do some more work on this in the next few weeks. From mnoble at space.mit.edu Wed Feb 8 10:55:23 2006 From: mnoble at space.mit.edu (Michael Noble) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] slirp 1.7.8 released Message-ID: <20060208155523.GA12645@svoboda.mit.edu> Friends, Version 1.7.8 of SLIRP has been released to http://space.mit.edu/CXC/software/slang/modules/slirp Regards, Mike Noble ----------------------------------------------------------------------- Changes in v1.7.8 1. Enhanced preprocessing capabilities: - support conditional compilation directives in C/C++ headers - slirp_substitute_macro() was ill-conceived, and has been deprecated; its replacement is slirp_define_macro() - new #define annotation: cleaner equivalent of slirp_define_macro() - new #undef annotation : companion to #define - Allow preprocessing tokens within enumerations 2. New examples: - complete examples/opengl demo (exercises preprocessor and -stubs) - show how to use an OUTPUT argmap to effectively morph a FORTRAN subroutine into a function 3. Ensure -tmapin/-tmapout do not reflect stubbed/temp types 4. Improved line number diagnostics when reporting malformed code 5. Enhanced Makefile generation: - fix IFLAGS typo - ensure code generated by-stubs is reflected in generated Makefiles 6. Extensive restructuring of the documentation, to reflect new features and better organize the content for existing ones. From s-lang at ottolander.nl Wed Feb 15 10:12:36 2006 From: s-lang at ottolander.nl (Leonard den Ottolander) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] SLtt_initialize() Is_Fg_BGR vs. Is_Bg_BGR Message-ID: <1140016357.2488.28.camel@athlon> Hi, In SLtt_initialize() the assignments of Is_Fg_BGR have been commented out and the variable has been dropped, but Is_Bg_BGR is still available as a variable. Don't we need the first variable any more? And doesn't the second need to be set conditionally? Pavel Shirshov recently fixed the internal slang version for mc to set Is_Bg_BGR (instead of Is_Fg_BGR) after the assignment of Color_Bg_Str on line 2562 in sldisply.c. Could this typo have been the cause of why you've dropped that variable Is_Fg_BGR altogether? Leonard -- mount -t life -o ro /dev/dna /genetic/research From davis at space.mit.edu Wed Feb 15 10:31:04 2006 From: davis at space.mit.edu (John E. Davis) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] SLtt_initialize() Is_Fg_BGR vs. Is_Bg_BGR In-Reply-To: <1140016357.2488.28.camel@athlon> References: <1140016357.2488.28.camel@athlon> Message-ID: <200602151531.k1FFV4xT027382@aluche.mit.edu> Leonard den Ottolander wrote: >In SLtt_initialize() the assignments of Is_Fg_BGR have been commented >out and the variable has been dropped, but Is_Bg_BGR is still available >as a variable. Don't we need the first variable any more? And doesn't >the second need to be set conditionally? The first variable (Is_Fg_BGR) was set but has never been used for anything. >Pavel Shirshov recently fixed the internal slang version for mc to set >Is_Bg_BGR (instead of Is_Fg_BGR) after the assignment of Color_Bg_Str on >line 2562 in sldisply.c. Could this typo have been the cause of why >you've dropped that variable Is_Fg_BGR altogether? Looking at the code, I can see how a typo could have caused Is_Fg_BGR to never be used. Does this patch address the issue? Thanks, --John --- sldisply.c~ 2006-02-05 14:56:06.000000000 -0500 +++ sldisply.c 2006-02-15 10:28:27.000000000 -0500 @@ -158,7 +158,7 @@ static Brush_Info_Type Brush_Table[JMAX_COLORS]; /* 0 if least significant bit is blue, not red */ -/* static int Is_Fg_BGR = 0; */ +static int Is_Fg_BGR = 0; static int Is_Bg_BGR = 0; #define COLOR_ARG(color, is_bgr) ((is_bgr) ? RGB_to_BGR[(color)&0x7] : (color)) static SLCONST int RGB_to_BGR[] = @@ -1394,7 +1394,7 @@ if (fg0 == SLSMG_COLOR_DEFAULT) tt_write_string (Default_Color_Fg_Str); else - tt_printf (Color_Fg_Str, COLOR_ARG(fg0, Is_Bg_BGR), 0); + tt_printf (Color_Fg_Str, COLOR_ARG(fg0, Is_Fg_BGR), 0); } if (unknown_attributes @@ -2554,13 +2554,13 @@ if (Color_Fg_Str == NULL) { Color_Fg_Str = SLtt_tgetstr ("Sf"); /* setf */ - /* Is_Fg_BGR = (Color_Fg_Str != NULL); */ + Is_Fg_BGR = (Color_Fg_Str != NULL); } Color_Bg_Str = SLtt_tgetstr ("AB"); /* ANSI setbf */ if (Color_Bg_Str == NULL) { Color_Bg_Str = SLtt_tgetstr ("Sb"); /* setb */ - /* Is_Fg_BGR = (Color_Bg_Str != NULL); */ + Is_Bg_BGR = (Color_Bg_Str != NULL); } if ((Max_Terminfo_Colors = SLtt_tgetnum ("Co")) < 0) From s-lang at ottolander.nl Wed Feb 15 10:43:06 2006 From: s-lang at ottolander.nl (Leonard den Ottolander) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] SLtt_initialize() Is_Fg_BGR vs. Is_Bg_BGR In-Reply-To: <200602151531.k1FFV4xT027382@aluche.mit.edu> References: <1140016357.2488.28.camel@athlon> <200602151531.k1FFV4xT027382@aluche.mit.edu> Message-ID: <1140018186.2488.35.camel@athlon> Hi John, On Wed, 2006-02-15 at 10:31 -0500, John E. Davis wrote: > Leonard den Ottolander wrote: > The first variable (Is_Fg_BGR) was set but has never been used for > anything. > > >Pavel Shirshov recently fixed the internal slang version for mc to set > >Is_Bg_BGR (instead of Is_Fg_BGR) after the assignment of Color_Bg_Str on > >line 2562 in sldisply.c. Could this typo have been the cause of why > >you've dropped that variable Is_Fg_BGR altogether? > > Looking at the code, I can see how a typo could have caused > Is_Fg_BGR to never be used. Does this patch address the issue? I'm not seeing any issues (not saying they're not there though), just reporting an apparent inconsistency. > Color_Bg_Str = SLtt_tgetstr ("Sb"); /* setb */ > - /* Is_Fg_BGR = (Color_Bg_Str != NULL); */ > + Is_Bg_BGR = (Color_Bg_Str != NULL); This is indeed the assignment Pavel Shirshov changed. It seems obvious (on the surface) that if you're still using Is_Bg_BGR it should be assigned here, or at least that this was the original intention of the author. But you are probably a better judge of that ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From merlin at ds2.uw.edu.pl Thu Feb 16 15:07:41 2006 From: merlin at ds2.uw.edu.pl (Rafal Muzylo) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] Question about SLANG_HAS_KANJI_SUPPORT feature Message-ID: <20060216200741.GC18768@jester.ds2.uw.edu.pl> What did that feature do in pre-2.0 versions of slang ? Is it still necessary in post-2.0 in UTF-8 mode and in not-UTF-8 modes ? If so, is it going to be fixed, cause as far as I can tell those three code blocks missed the moment when SLsmg_Char_Type stopped being unsigned short and became a struct. From davis at space.mit.edu Tue Feb 21 03:15:41 2006 From: davis at space.mit.edu (John E. Davis) Date: Tue Jan 30 08:52:10 2007 Subject: [slang-users] Question about SLANG_HAS_KANJI_SUPPORT feature In-Reply-To: <20060216200741.GC18768@jester.ds2.uw.edu.pl> References: <20060216200741.GC18768@jester.ds2.uw.edu.pl> Message-ID: <200602210815.k1L8FfiV008289@aluche.mit.edu> Rafal Muzylo wrote: >What did that feature do in pre-2.0 versions of slang ? It added support for Kanji terminals. I see that there is no comment in sl-feat.h indicating that the Kanji support in slang-2 is broken. It worked in slang-1 but I have no idea how well. Most apps that make use of the SLtt interface do so through the higher-level SLsmg one. However, the slang-1 SLsmg functions know nothing about multi-byte and double width characters. >Is it still necessary in post-2.0 in UTF-8 mode and in not-UTF-8 modes ? I see no reason for it in UTF-8 mode. To what extent is Kanji being replaced by Unicode? >If so, is it going to be fixed, cause as far as I can tell those three >code blocks missed the moment when SLsmg_Char_Type stopped being >unsigned short and became a struct. Feel free to send me patches to correct the problem. Unfortunately, other than making sure it compiles cleanly, I will not be able to test the patches, nor would I trust myself to perform such tests. Thanks, --John