bashburn-info Mailing List for BashBurn (Page 8)
Brought to you by:
bashburn
Menu
▾
▴
bashburn-info — BashBurn mailing list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(3) |
Mar
|
Apr
(31) |
May
(5) |
Jun
(10) |
Jul
(21) |
Aug
(9) |
Sep
(9) |
Oct
(5) |
Nov
|
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(6) |
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
(7) |
Nov
(3) |
Dec
(17) |
| 2007 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(8) |
Aug
(114) |
Sep
(283) |
Oct
(128) |
Nov
|
Dec
(1) |
|
From: Steven W. O. <st...@sy...> - 2008-09-29 13:18:48
|
On Monday, Sep 29th 2008 at 06:37 -0000, quoth Nick Warne: => =>I have hardened the Install file options, after I noticed some strange =>behaviour with silly options (i.e. -uninstall ). => =>There is still a big issue if you use: => =>-prefix=/usr => =>The install script will install into a directory called 'refix' in the =>current directory. => =>Nick That should not happen. I'll look at it. :-( (after svn comes back up) -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
|
From: Nick W. <ni...@li...> - 2008-09-29 13:15:21
|
On Mon, 29 Sep 2008 09:08:21 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > 520 > svn update > svn: PROPFIND request failed on '/svn/bashburn/trunk' > svn: PROPFIND of '/svn/bashburn/trunk': 501 Not Implemented > (https://svn.inf.sgsp.edu.pl) > 520 > > > > Anyone? > The svn server is AWOL again. I guess we have to wait. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-29 13:08:38
|
520 > svn update svn: PROPFIND request failed on '/svn/bashburn/trunk' svn: PROPFIND of '/svn/bashburn/trunk': 501 Not Implemented (https://svn.inf.sgsp.edu.pl) 520 > Anyone? -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
|
From: Nick W. <ni...@li...> - 2008-09-29 11:21:45
|
On Mon, 29 Sep 2008 11:37:20 +0100 Nick Warne <ni...@li...> wrote: > > I have hardened the Install file options, after I noticed some strange > behaviour with silly options (i.e. -uninstall ). > > There is still a big issue if you use: > > -prefix=/usr > > The install script will install into a directory called 'refix' in the > current directory. OK, I hardened this a bit more. Single options are now UPPER case. Still breaks bad if you specify -P<something here> though, i.e. -Px will install to a directory called 'x' in current location. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-29 10:37:26
|
I have hardened the Install file options, after I noticed some strange behaviour with silly options (i.e. -uninstall ). There is still a big issue if you use: -prefix=/usr The install script will install into a directory called 'refix' in the current directory. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-29 09:05:17
|
I have committed a few fixes today. The information header/footer wasn't being sourced corrected (and thus not diosplayed), so I moved it to the top of misc/commonfunctions.sh. I think that is the right thing to do. Also even if I went into a configure menu and changed nothing, I was told I changed something, and did I apply changes? I traced this due to a script error show at the same time. It appears there was a mix of boolean and comparison in func/configfunc.sh line 32. Again, I think that is the right thing to do. Steve: Should we just treat BB_CONFIG_VAR, BB_ADVANCED_CONFIG_MODIFIED & BB_CONFIG_MODIFIED real booleans? Lastly, .bashburnrc now has a version control $VAR. This would need to be changed (and the test for it) if the functionality ever changes again and a user needs to remove the old .bashburnrc. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-29 06:42:49
|
On Sun, 28 Sep 2008 22:09:46 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > func/definefunc.sh > Missing all of the variables that it uses. > > bb_dc_* > > Anyone? I don't know what you mean - do you mean they are not defined anywhere? Have a look at lang/<LANG>/datadefine.lang file. All works OK for me here. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-29 02:43:45
|
On Sunday, Sep 28th 2008 at 22:09 -0000, quoth Steven W. Orr: =>func/definefunc.sh =>Missing all of the variables that it uses. => =>bb_dc_* => =>Anyone? Also, bb_lb* used in loopback.sh -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
|
From: Steven W. O. <st...@sy...> - 2008-09-29 02:10:05
|
func/definefunc.sh Missing all of the variables that it uses. bb_dc_* Anyone? -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Steven W. O. <st...@sy...> - 2008-09-28 22:43:26
|
It looks like the email is down again. I made changes to audiofunc. I'm sort of surprised that no one spotted the problems plural. I hope they're fixed. I also just changed the sed command that I desperately hate in audiofunc::named so that it's actually intelligible. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Steven W. O. <st...@sy...> - 2008-09-28 15:14:17
|
On Sunday, Sep 28th 2008 at 02:50 -0000, quoth Nick Warne: =>On Sat, 27 Sep 2008 23:21:02 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> wait_for_enter now waits for any keypress. =>> message prints a message and calls wait_for_enter =>> =>> It's getting cleaner. =>> => =>This doesn't work (yet). => =>It appears misc/commonfunctions.sh doesn't get sourced until AFTER the =>function 'message' is called, when starting BB. => =>Secondly, even if I source that file first, then option 8) 'check =>paths' doesn't work right. Nothing appears, but if you scroll up your =>terminal you will see the output above the bashburn menu. => =>Lastly, the new $VAR bb_hit_any_key_to_continue doesn't seem to get =>assigned, so the 'wait_for_enter' prompts are empty like this Ok, let's try again. :-( I think I fixed it (let me know), but there's a problem brewing here that I think needs to be addressed sooner than later. That problem is src code structure. This whole thing feels to me like it's getting fragile. As I'm writing this I see a total of 10334 lines of src code. And all of that src code is broken up into seperate modules that have a sort of mishmashed logic to it all. I suspect that there was some sort of rhyme or reason to it all earlier in the game, but at this point it's starting to feel unwieldy. I need to throw out a couple of examples. We have a directory called menu. (Almost) None of the files in that directory are in any way related to each other other than the fact that they call bbmenu in some way. Even before I wrote bbmenu it didn't matter; they still were not fundamentally related. There were a collection of modules that all produced different menus, but they still were not related. Let's look at configuration. We have menus/configure.sh, func/configfunc.sh, misc/commands.idx, and the granddaddy of all garbage dumps, misc/commonfunctions.sh Let's look at filename extensions. We have lang files sitting in lang directories. We have idx files and I don't even know what those mean. Before I got into this, the big difference was that bb was cranking huge numbers of processes. But that characteristic is a runtime aspect. What I'm talking about here is src code respository shape. And as a side note, one of the things that we're doing right is to always execute from an installed release. We no longer execute anything from a workspace. But, what we're not asking ourselves is whether the installed tree structure is something that is supposed to look like the repository structure. End of long ramble. Please, thots anyone? -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Nick W. <ni...@li...> - 2008-09-28 07:20:06
|
On Sun, 28 Sep 2008 07:50:03 +0100 Nick Warne <ni...@li...> wrote: > On Sat, 27 Sep 2008 23:21:02 -0400 (EDT) > "Steven W. Orr" <st...@sy...> wrote: > > > wait_for_enter now waits for any keypress. > > message prints a message and calls wait_for_enter > > > > It's getting cleaner. > > > > This doesn't work (yet). > > It appears misc/commonfunctions.sh doesn't get sourced until AFTER the > function 'message' is called, when starting BB. > > Secondly, even if I source that file first, then option 8) 'check > paths' doesn't work right. Nothing appears, but if you scroll up your > terminal you will see the output above the bashburn menu. > > Lastly, the new $VAR bb_hit_any_key_to_continue doesn't seem to get > assigned, so the 'wait_for_enter' prompts are empty like this > > : OK, I fixed up the check paths function... it now operations as before. There still is the issue of the misc/commonfunctions.sh file not being sourced at the right time in BashBurn.sh, though. OK, perfect weather here today for a long bike ride into the countryside. I have to get off now before the damn motorists all get out and about. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-28 06:50:15
|
On Sat, 27 Sep 2008 23:21:02 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > wait_for_enter now waits for any keypress. > message prints a message and calls wait_for_enter > > It's getting cleaner. > This doesn't work (yet). It appears misc/commonfunctions.sh doesn't get sourced until AFTER the function 'message' is called, when starting BB. Secondly, even if I source that file first, then option 8) 'check paths' doesn't work right. Nothing appears, but if you scroll up your terminal you will see the output above the bashburn menu. Lastly, the new $VAR bb_hit_any_key_to_continue doesn't seem to get assigned, so the 'wait_for_enter' prompts are empty like this : Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-28 03:21:16
|
wait_for_enter now waits for any keypress. message prints a message and calls wait_for_enter It's getting cleaner. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Anders L. <and...@gm...> - 2008-09-27 15:20:52
|
lör 2008-09-27 klockan 14:29 +0100 skrev Nick Warne: > I was thinking with the new version, if a user has the old > installation, and retains their original .bashburnrc file, this could > cause problems as unspecified errors happen when starting. > > What about if we prepend a version header on the .bashburnrc file, sort > of like: > > # BashBurn 3.x.x file > > and if the new version doesn't find that header, then abort the start > with instructions that the user has to delete it and re-configure from > afresh for the new BashBurn version? > > Nick Sounds like a good idea. -- Anders Lindén http://bashburn.sf.net |
|
From: Nick W. <ni...@li...> - 2008-09-27 13:30:04
|
I was thinking with the new version, if a user has the old installation, and retains their original .bashburnrc file, this could cause problems as unspecified errors happen when starting. What about if we prepend a version header on the .bashburnrc file, sort of like: # BashBurn 3.x.x file and if the new version doesn't find that header, then abort the start with instructions that the user has to delete it and re-configure from afresh for the new BashBurn version? Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-27 08:43:13
|
Begin forwarded message: Date: Thu, 25 Sep 2008 22:01:06 +0100 From: Nick Warne <ni...@li...> To: "Steven W. Orr" <st...@sy...> Cc: bashburn <Bas...@li...> Subject: Re: [Bashburn-info] Something funky in the config menu On Thu, 25 Sep 2008 10:56:12 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > Nick, Maybe I'm not getting it. I sense that CTH.lang is used as a > stopgap to provide in case a language is not supported. But if we're > in Swahili and the language is not supported then we should default > to English instead of creating a copy of an English language file. At > the most, we should be looking to see in BBLANG is in the set of > supported languages and if it's not then set it to English. Yes? No? Yes and no. Look at the lang/Italian/configure.lang file (e.g.) It does not HAVE the $VARs associated with the help file, whether it is in Swahili, Klingon, or any other language. If the $VARs do not exist, then nothing gets sourced and no help text when it that language. The rest of the file[s] for menu etc. work OK... so it cannot just be reverted to English as default - just the 'not updated' variables in these files. Nick -- Free Software Foundation Associate Member 5508 -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-27 08:42:49
|
Begin forwarded message: Date: Fri, 26 Sep 2008 07:33:17 +0100 From: Nick Warne <ni...@li...> To: "Steven W. Orr" <st...@sy...> Cc: bashburn <bas...@li...> Subject: Re: [Bashburn-info] Dodgy BUG On Thu, 25 Sep 2008 21:32:04 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > =>> As it sits now, it has nothingh to do with bb. > => > =>OK. Is/could it be a problem though? Is there no way to catch the > =>escape key? > => > =>I mean, who would press escape key 3 or 4 times other than a moron > like =>me :-) > > I'm actually slightly intrigued by this because I don't see where > the definition is. The bash man page gives all of the function > definitions and all of their default bindings. None of the default > bindings correspond to M-<ESC>. (BTW, to activate it, you don't need > to hit it three or four times. Exactly two will do it. Or hold the > Alt key while hitting escape.) > > Intrigued, but not intrigued enough to chase it. ;-) OK, I found out what this is - file name completion. The same issue happens in BB if you hit the TAB key twice. Basically, as there is no file name specified, the command (cleverly) asks if you want to see all the files. Nick -- Free Software Foundation Associate Member 5508 -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-27 08:36:59
|
On Sat, 27 Sep 2008 00:05:43 +0200 Anders Lindén <and...@gm...> wrote: > Hah! Always expect the unexpected! Not asleep yet, to busy playing > Burnout Paradise on the PS3 to go to sleep. > > Steven, I suspect there might be some issues with the mailing list > because of the sourceforge move. > I'll check with Elvis (The admin of the new webpage server) if he > could set up a mailing list on the server. Perhaps it would be a good > idea to move the list over there. They have been having too many > issues for me lately. > Of course, if you're willing you could always resurecct the old > mailing list on your server and we could use that instead. I don't > remember any issues when you were in charge. :-) According to the SF ststus page, all mailing lists are working and functioning correctly. I don't think so. Perhaps it would be wise to move. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-26 19:49:54
|
On Fri, 26 Sep 2008 12:37:39 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Friday, Sep 26th 2008 at 12:13 -0000, quoth Nick Warne: > > => > =>I sent a few mails today - none have arrived. > => > =>Anybody else in the same boat? > => > =>Nick > =>-- > =>Free Software Foundation Associate Member 5508 > => > > Mee too. And I said some important things! > > Check the code changes :-) Steve, I disagree with changed back the 'sleep 7' to 'sleep 2' in BashBurn.sh line 340. The reason I done this is due to time to read the the output. A user installing will ONLY ever see this dialogue once. She has to be allowed to read the dialogue in ample time. 2 seconds is too fast. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-26 15:49:33
|
There's a new param in conf_menuitems (See the setup for BBLANG) which if true says that we are enforcing strict enumerations. The user gets the list of choices, but if he picks something outside of the list then it is summarily rejected. (I also found a bug. 40 quatloos if you can see it.) -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Steven W. O. <st...@sy...> - 2008-09-26 15:07:53
|
On Thursday, Sep 25th 2008 at 17:01 -0000, quoth Nick Warne: =>On Thu, 25 Sep 2008 10:56:12 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> Nick, Maybe I'm not getting it. I sense that CTH.lang is used as a =>> stopgap to provide in case a language is not supported. But if we're =>> in Swahili and the language is not supported then we should default =>> to English instead of creating a copy of an English language file. At =>> the most, we should be looking to see in BBLANG is in the set of =>> supported languages and if it's not then set it to English. Yes? No? => =>Yes and no. Look at the lang/Italian/configure.lang file (e.g.) => =>It does not HAVE the $VARs associated with the help file, whether it is =>in Swahili, Klingon, or any other language. If the $VARs do not exist, =>then nothing gets sourced and no help text when it that language. => =>The rest of the file[s] for menu etc. work OK... so it cannot just be =>reverted to English as default - just the 'not updated' variables in =>these files. Sorry, not clear yet. Proposal: I will change bb so that when BBLANG gets set, it will only be allowed to be set to an approved value. If the value that the user tries to set it to or if the value in the .bashburnrc is not a supported value then it will be set to English as the default value. Does that work? This implies that if we have a directory for a language, then we must have all variables defined. So, if a new language is created then the proper way to do it is to copy the English directory and then make changes until none of the content is left as English. And to followup, do we have undefined variables in any of the lang subdirs? -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Nick W. <ni...@li...> - 2008-09-26 06:33:30
|
On Thu, 25 Sep 2008 21:32:04 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > =>> As it sits now, it has nothingh to do with bb. > => > =>OK. Is/could it be a problem though? Is there no way to catch the > =>escape key? > => > =>I mean, who would press escape key 3 or 4 times other than a moron > like =>me :-) > > I'm actually slightly intrigued by this because I don't see where > the definition is. The bash man page gives all of the function > definitions and all of their default bindings. None of the default > bindings correspond to M-<ESC>. (BTW, to activate it, you don't need > to hit it three or four times. Exactly two will do it. Or hold the > Alt key while hitting escape.) > > Intrigued, but not intrigued enough to chase it. ;-) OK, I found out what this is - file name completion. The same issue happens in BB if you hit the TAB key twice. Basically, as there is no file name specified, the command (cleverly) asks if you want to see all the files. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-26 02:47:21
|
On Thursday, Sep 25th 2008 at 16:53 -0000, quoth Nick Warne: =>On Thu, 25 Sep 2008 11:31:01 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> On Thursday, Sep 25th 2008 at 09:58 -0000, quoth Nick Warne: =>> =>> =>OK, I just discovered a dodgy bug. =>> => =>> =>Go to any menu, and hit escape key 3 or 4 times. You get a full =>> =>offered a full directory listing. =>> => =>> =>I guess we need to assign this key similar to SIGNAL type =>> assignment. => =>> =>Nick =>> =>> That's a feature. :-) =>> =>> I'm not exactly sure what it's hooked up to but it's a readline =>> thing, one of the Completing commands. This one completes based on =>> all possible commands. It's probably one of these: =>> =>> possible-command-completions (C-x !) =>> List the possible completions of the text before point, =>> treating it as a command name. =>> dynamic-complete-history (M-TAB) =>> Attempt completion on the text before point, comparing =>> the text against lines from the history list for possible =>> completion matches. =>> =>> If it's *really* a problem, we could create an inputrc for bb to have =>> an alternate initialization of readline. =>> =>> As it sits now, it has nothingh to do with bb. => =>OK. Is/could it be a problem though? Is there no way to catch the =>escape key? => =>I mean, who would press escape key 3 or 4 times other than a moron like =>me :-) I'm actually slightly intrigued by this because I don't see where the definition is. The bash man page gives all of the function definitions and all of their default bindings. None of the default bindings correspond to M-<ESC>. (BTW, to activate it, you don't need to hit it three or four times. Exactly two will do it. Or hold the Alt key while hitting escape.) Intrigued, but not intrigued enough to chase it. ;-) -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
|
From: Anders L. <and...@gm...> - 2008-09-25 23:12:51
|
> OK. Is/could it be a problem though? Is there no way to catch the > escape key? > > I mean, who would press escape key 3 or 4 times other than a moron like > me :-) > Very true. You're one of a kind Nick. :-) No, I don't think this is much of a problem. I find it very unlikely that a lot of people will press the escape key that many times to trigger this behaviour. > Nick -- Anders Lindén http://bashburn.sf.net |
8 messages has been excluded from this view by a project administrator.
