Re: Unifying Exception types in setup
Robert Collins wrote: Max Bowsher wrote: Robert, Currently setup uses both stdexcept exceptions, and its own std::exception-derived Exceptions. I'm about to write a patch to convert the kludgy if (error) exit(some_random_exit_code); bits to exceptions. Which kind shall I use, and would you be interested in a patch to convert all of them over to one kind? Max. I need to think on this. OK. How about I convert the kludgy exits to Exceptions, and change them to stdexcepts later, along with the rest, if that's what you decide? Max.
Re: Unifying Exception types in setup
On Sun, 16 Mar 2003, Max Bowsher wrote: Robert Collins wrote: Max Bowsher wrote: Robert, Currently setup uses both stdexcept exceptions, and its own std::exception-derived Exceptions. I'm about to write a patch to convert the kludgy if (error) exit(some_random_exit_code); bits to exceptions. Which kind shall I use, and would you be interested in a patch to convert all of them over to one kind? Max. I need to think on this. OK. How about I convert the kludgy exits to Exceptions, and change them to stdexcepts later, along with the rest, if that's what you decide? Just chaging exit() - throw Exception won't help much. There should be an exception handler installed who takes care of processing these exceptions i.e. shutdown setup with a simple message describing the situation. If you going to do this I suggest you to dereive a new class from exception or Exception, say FatalException. Then install a global handler, which catches FatalException and displays a message then exits. This way the exit call will be in a single place and not scattered throught the code. Btw why do you want to use a single exception type ? IMO, this way you defeat the purpose of exceptions to a certain degree. Different exceptions should cover different types of errors/events - say IOException, CRCExcepion, AuthenticationException.
Re: nano editor : v.1.2.0 released
On Sun, 16 Mar 2003, Gareth Pearce wrote: A lil slow off the mark ... but here we go... http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1.tar.bz2 http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1-src.tar.bz2 http://www-personal.usyd.edu.au/~gpea0679/nano/setup.hint Uploaded. Don't forget to send an announcement to cygwin-announce.
Re: Unifying Exception types in setup
On Sun, 16 Mar 2003, Max Bowsher wrote: If you going to do this I suggest you to dereive a new class from exception or Exception, say FatalException. Then install a global handler, which catches FatalException and displays a message then exits. This way the exit call will be in a single place and not scattered throught the code. All exceptions are fatal if they get to the toplevel. Yep! Maybe I made a wrong example. My point was - no other exception should reach the toplevel except the the one designated to kill setup i.e. the one which you will use to replace the exit () calls. If another exception reaches then it should be treated as a bug. Unfortunately, we will require multiple toplevel catch blocks: One in each WndProc and thread initiation routine. Btw I remember that Robert had some concerns about exceptions and mingw. The info should be in the archives. And I don't know if these problems still exist.
mknetrel: avoid requiring (fake)root permission
I got a bugreport about ownership in the tetex package (it seems that people are actionally starting to use different users in Windows :-) but after fixing it I found a (different) fix already in CVS. Is there a reason for mknetrel to require (fake)root permissions? I'd like to suggest the patch below. Greetings, Jan. ChangeLog: 2003-03-16 Jan Nieuwenhuizen [EMAIL PROTECTED] * bin/mknetrel.cvs (domkdist): Fix permissions using tar options (Was: require [fake]root permissions). --- mknetrel8 Jan 2003 01:35:03 - 1.43 +++ mknetrel16 Mar 2003 12:18:10 - @@ -363,11 +363,10 @@ # Fix up installation slightly # cd $inst || exit 1 -chmod -R u+w,og-w . +chmod -R u+w,a+rX . cd usr 2/dev/null dousrstuff cd $inst || exit 1 -chown -R 0.0 . || . prepackage cd $inst || exit 1 @@ -379,12 +378,12 @@ # Make tar balls # echo creating $tarstem.tar.bz2 -find * -print | sort | tar -T - --no-recursion -cjf $tarstem.tar.bz2 +find * -print | sort | tar -T - --no-recursion --owner=0 --group=0 -cjf $tarstem.tar.bz2 cd $src/.. || exit 1 echo creating $tarstem-src.tar.bz2 -ls -d $package_src/* | egrep -v '\.cvsignore|\.bak$|\.orig$|\.o$|~$|^.#|CVS|%redact|/tags$' | egrep -v $src_exclude | tar -T - --no-recursion -chf $tarstem-src.tar -find $package_src/* -print -follow | egrep -v ^$package_src/[^/]*$ | egrep -v '\.cvsignore|\.bak$|\.orig$|\.o$|~$|^.#|CVS|%redact|/tags$' | egrep -v $src_exclude | sort | tee /tmp/huh | tar -T - --no-recursion -rf $tarstem-src.tar +ls -d $package_src/* | egrep -v '\.cvsignore|\.bak$|\.orig$|\.o$|~$|^.#|CVS|%redact|/tags$' | egrep -v $src_exclude | tar -T - --no-recursion --owner=0 --group=0 -chf $tarstem-src.tar +find $package_src/* -print -follow | egrep -v ^$package_src/[^/]*$ | egrep -v '\.cvsignore|\.bak$|\.orig$|\.o$|~$|^.#|CVS|%redact|/tags$' | egrep -v $src_exclude | sort | tee /tmp/huh | tar -T - --no-recursion --owner=0 --group=0 -rf $tarstem-src.tar bzip2 -f $tarstem-src.tar postpackage } -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
mknetrel: symlink fix for absent usr/bin
I've posted a simple fix for symlinks quite a while ago, but I found a more fragile variant in CVS today. I'd like to suggest something like I have been using, below. Greetings, Jan. 2003-03-16 Jan Nieuwenhuizen [EMAIL PROTECTED] * bin/mknetrel.pats2 (dousrstuff): Don't fail if usr/bin is absent. --- mknetrel8 Jan 2003 01:35:03 - 1.43 +++ mknetrel16 Mar 2003 12:44:02 - @@ -322,8 +322,7 @@ rm -rf i686-pc-cygwin -cd bin -for f in *; do +(cd bin for f in *; do case $f in *.exe|*\*) continue ;; esac @@ -337,9 +336,8 @@ ln -s $ln.exe $f.exe ;; esac -done +done) -cd .. for f in bin/* sbin/*; do case $f in *.exe) ;; -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
String and std::string
I've been toying with some ideas for UserSetting persistence in setup.conf, and have run into the following issue: String, from String++.* lacks some functionality I need. std::string has the necessary functionality. Is one of String and std::string deprecated as far as setup is concerned? Are there any features String has but std::string does not? Should I add the needed functionality to String, or convert all relevant parts of setup away from String, to std::string? Max.
Re: String and std::string
Pavel Tsekov wrote: On Sun, 16 Mar 2003, Max Bowsher wrote: I've been toying with some ideas for UserSetting persistence in setup.conf, and have run into the following issue: String, from String++.* lacks some functionality I need. std::string has the necessary functionality. Is one of String and std::string deprecated as far as setup is concerned? Are there any features String has but std::string does not? Except for casecompare() I think not. Of course you can perform caseless comparison with std::string. It's just a bit tricky :). Hint: char_traits. What fun. I think it's time to improve my STL knowledge. And there is the other difference that string is standard. Should I add the needed functionality to String, or convert all relevant parts of setup away from String, to std::string? This will require a BIG patch. Yep! There was a short discussion in the past about this I think. Can anyone point me to it? String doesn't make a very good search term! Max.
Re: String and std::string
On Sun, 16 Mar 2003, Max Bowsher wrote: Are there any features String has but std::string does not? Except for casecompare() I think not. Of course you can perform caseless comparison with std::string. It's just a bit tricky :). Hint: char_traits. What fun. I think it's time to improve my STL knowledge. Not STL, C++ :) There was a short discussion in the past about this I think. Can anyone point me to it? String doesn't make a very good search term! Look for 'japanese' :)) You'll find it easily. There are other interesting topic around that one.
Re: Unifying Exception types in setup
Pavel Tsekov wrote: On Sun, 16 Mar 2003, Max Bowsher wrote: If you going to do this I suggest you to dereive a new class from exception or Exception, say FatalException. Then install a global handler, which catches FatalException and displays a message then exits. This way the exit call will be in a single place and not scattered throught the code. All exceptions are fatal if they get to the toplevel. Yep! Maybe I made a wrong example. My point was - no other exception should reach the toplevel except the the one designated to kill setup i.e. the one which you will use to replace the exit () calls. If another exception reaches then it should be treated as a bug. Unfortunately, we will require multiple toplevel catch blocks: One in each WndProc and thread initiation routine. Actually, I've just read about set_terminate(), and I'm not so sure about this now. I wonder how exceptions interact with WndProcs. Will they stop unwinding when they reach the end of the applications code, or will they unwind through the guts of Windows, and (maybe?) emerge back in main? Does it matter? Btw I remember that Robert had some concerns about exceptions and mingw. The info should be in the archives. And I don't know if these problems still exist. No luck searching. Exception produces far too many useless hits.
Re: String and std::string
Pavel Tsekov wrote: On Sun, 16 Mar 2003, Max Bowsher wrote: Are there any features String has but std::string does not? Except for casecompare() I think not. Of course you can perform caseless comparison with std::string. It's just a bit tricky :). Hint: char_traits. What fun. I think it's time to improve my STL knowledge. Not STL, C++ :) There was a short discussion in the past about this I think. Can anyone point me to it? String doesn't make a very good search term! Look for 'japanese' :)) You'll find it easily. There are other interesting topic around that one. That curiously random search term was very useful. I found some clear info from Robert about Exception. Rather less on std::string vs. String. I'll wait for an answer to my previous questions. Max.
Re: Unifying Exception types in setup
On Sun, 16 Mar 2003, Max Bowsher wrote: Btw I remember that Robert had some concerns about exceptions and mingw. The info should be in the archives. And I don't know if these problems still exist. No luck searching. Exception produces far too many useless hits. http://www.cygwin.com/ml/cygwin-apps/2002-04/msg00650.html Start here and goes on. Here is some chat about strings. http://www.cygwin.com/ml/cygwin-apps/2002-05/msg1.html Interesting discussions. I'm rereading them too.
Re: nano editor : v.1.2.0 released
On Sun, Mar 16, 2003 at 11:57:38AM +0100, Pavel Tsekov wrote: On Sun, 16 Mar 2003, Gareth Pearce wrote: A lil slow off the mark ... but here we go... http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1.tar.bz2 http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1-src.tar.bz2 http://www-personal.usyd.edu.au/~gpea0679/nano/setup.hint Uploaded. Don't forget to send an announcement to cygwin-announce. And next time please don't include _update?info?dir in your setup.hint. That gets added automatically if needed. It was misspelled in the setup.hint that was uploaded to sources.redhat.com, resulting in hundreds of messages in my inbox. I didn't catch this immediately because I was out of town. cgf
Re: nano editor : v.1.2.0 released
On Sun, 16 Mar 2003, Christopher Faylor wrote: On Sun, Mar 16, 2003 at 11:57:38AM +0100, Pavel Tsekov wrote: On Sun, 16 Mar 2003, Gareth Pearce wrote: A lil slow off the mark ... but here we go... http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1.tar.bz2 http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1-src.tar.bz2 http://www-personal.usyd.edu.au/~gpea0679/nano/setup.hint Uploaded. Don't forget to send an announcement to cygwin-announce. And next time please don't include _update?info?dir in your setup.hint. That gets added automatically if needed. It was misspelled in the setup.hint that was uploaded to sources.redhat.com, resulting in hundreds of messages in my inbox. I didn't catch this immediately because I was out of town. My fault. I caught this - the new requirement not the typo. Then I looked at bash's setup hint and saw that it is there also so I thought it is ok.
Re: ExitProcess or exit?
On Sun, 2003-03-16 at 01:01, Max Bowsher wrote: #ifndef _CYGWIN_ ExitProcess (1); #else exit (1); #endif I'm puzzled by the above. Shouldn't we be giving MSVCRT the opportunity to run any shutdown it wishes to? Well ExitProcess is the windows API exit call. Is there a MSVCRT exit() ? Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Partial vs. strict weak ordering (was Re: [PATCH] Postinstall script ordering in setup - take 3)
On 16 Mar 2003, Robert Collins wrote: On Sat, 2003-03-15 at 09:33, Igor Pechtchanski wrote: Rob, Your operator and appear to have a problem. foo: bar gam: bar foo gam= false gam foo= false gam == foo = false. I'd expect stl associative containers to choke on that. Not really. I read up on that specifically. stl containers only need a *partial* order. What you're suggesting will create a total order. Not an error, but overkill. The sort function is supposed to be stable and keep the original order if the lessThan relation is undefined. See http://www.sgi.com/tech/stl/LessThanComparable.html = Consider the relation !(x y) !(y x). If this relation is transitive (that is, if !(x y) !(y x) !(y z) !(z y) implies !(x z) !(z x)), then it satisfies the mathematical definition of an equivalence relation. In this case, operator is a strict weak ordering. If operator is a strict weak ordering, and if each equivalence class has only a single element, then operator is a total ordering. Valid expressions Name Expression Type requirements Return type Less x y Convertible to bool Greater x y Convertible to bool Less or equal x = y Convertible to bool Greater or equal x = y Convertible to bool Expression semantics Name Expression Precondition Semantics Postcondition Less x y x and y are in the domain of Greater x y x and y are in the domain of Equivalent to y x [1] Less or equal x = y x and y are in the domain of Equivalent to !(y x) [1] Greater or equal x = y x and y are in the domain of Equivalent to !(x y) [1] Complexity guarantees Invariants Irreflexivity x x must be false. Antisymmetry x y implies !(y x) [2] Transitivity x y and y z implies x z [3] Models * int Notes [1] Only operator is fundamental; the other inequality operators are essentially syntactic sugar. [2] Antisymmetry is a theorem, not an axiom: it follows from irreflexivity and transitivity. [3] Because of irreflexivity and transitivity, operator always satisfies the definition of a partial ordering. The definition of a strict weak ordering is stricter, and the definition of a total ordering is stricter still. = foo: bar gam: bar gives foo bar gam bar from above: Axiom: ! (foo gam) (! gam foo) Axiom: ! (foo gam) (! gam foo) !(gam z) !(z gam) is !(foo z) (!z foo) ever false? now, foo is z when z depends on foo. !(foo z) means z does not depend on foo. what do we know about z? z does not depend on gam. !(gam z) gam does not depend on z !(z gam) can z depend on foo and not on gam? let z depend on foo: so: z foo. now, !(gam z) is still true. !(z gam) is still true. !(foo z) is false. Yes. It reads better this way: !(x y) !(y x) === unordered(x,y) Reflexivity: unordered(x,x) Transitivity: unordered(x,y) unordered(y,z) = unordered(x,z) And I agree that unordered(x,y) defined in terms of my operator is *not* transitive. Thus, my operator is not a strict weak ordering. It *is*, however, a partial ordering (see note [3] above). Your operator is not a equivalence relation. Now, operator is *never* an equivalence relation (because it's irreflexive, rather than reflexive). My operator *is* transitive, because of the propagateDependences step... STL Containers will choke. You fail on transitivity BTW. Rob STL containers won't choke, as they only need a partial order, AFAIU. The fail simply means it's not a strict weak ordering. Now, what my operator *does* fail on is irreflexivity (in case there are circular dependences). I'll need to fix that (it's a TODO). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: Unifying Exception types in setup
On Sun, 2003-03-16 at 20:34, Max Bowsher wrote: Robert Collins wrote: Max Bowsher wrote: Robert, Currently setup uses both stdexcept exceptions, and its own std::exception-derived Exceptions. I'm about to write a patch to convert the kludgy if (error) exit(some_random_exit_code); bits to exceptions. Which kind shall I use, and would you be interested in a patch to convert all of them over to one kind? Max. I need to think on this. OK. How about I convert the kludgy exits to Exceptions, and change them to stdexcepts later, along with the rest, if that's what you decide? Well, if the thread limitations for c++ exceptions on mingw have been resolved (have they?) we can start widespread use of exceptions. Until now we've been limited to using them in race-safe ways. (i.e. one context / thread at a time). The exits that are marked /* XXX FIXME use an exception */ or similar are good to be converted. They must not be caught within setup (because these bits of code are by definition something we can't handle). (Perhaps - only perhaps - via a terminate handler.). So subclassing Exception will only do if they will be thrown again under any circumstance. Ditto. Before doing this, please test (via a test_foo program, I want to be able to detect gcc regressions should they occur) for cross-thread-unhandled-exception behaviour and message-handler-owned-thread exception behaviour. Specifically, main() won't see most, if any exceptions. The 'new' failure checks should be fine - simply put a little test in to use up all your ram and see if a new exception is thrown. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Unifying Exception types in setup
On Sun, 2003-03-16 at 21:24, Pavel Tsekov wrote: Just chaging exit() - throw Exception won't help much. There should be an exception handler installed who takes care of processing these exceptions i.e. shutdown setup with a simple message describing the situation. If you going to do this I suggest you to dereive a new class from exception or Exception, say FatalException. Then install a global handler, which catches FatalException and displays a message then exits. This way the exit call will be in a single place and not scattered throught the code. Yep, thats reasonable. terminate handlers can't return though, so we need a synchronous, non memory allocating, non resource using message display. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Unifying Exception types in setup
On Sun, 2003-03-16 at 21:53, Max Bowsher wrote: Makes sense. I'll wait for Robert to explain why setup has 2 different exception paradigms, and which one can be removed, and if we keep Exception, whether we can junk appErrNo, and replace it with derived classes as you suggest. appErrNo is useful because it allows easy discrimination between the exception that occured, without multiple catch blocks. I'm not wedded to it by any means though. Setup has the Exception class for it's own handleable exceptions. We use runtime_error for instance, because it's the appropriate exception for a runtime-error. For the bulk of the exit() calling routines, I suspect runtime_error is appropriate. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: String and std::string
On Mon, 2003-03-17 at 01:44, Max Bowsher wrote: I've been toying with some ideas for UserSetting persistence in setup.conf, and have run into the following issue: String, from String++.* lacks some functionality I need. std::string has the necessary functionality. Is one of String and std::string deprecated as far as setup is concerned? Are there any features String has but std::string does not? Should I add the needed functionality to String, or convert all relevant parts of setup away from String, to std::string? libgetopt++ has deprecated String++.h, but still has it IIRC for setup.exe compatability. std::string is good, but what we need is a Facade that allows resource loading (see Gary's string class too). I don't care whether you use std::string, or String++ for any new code, as long as: 1) You don't leak memory (std::string will leak if you use c_str()) IIRC. 2) You interoperate well with String++. I'm not interested in replacing String++ for the sake of replacing String++. If it's an impediment to you in a given area, then change that one area. Creating complementary constructors and assignment operators will help you there. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Unifying Exception types in setup
On Mon, 2003-03-17 at 02:24, Max Bowsher wrote: Unfortunately, we will require multiple toplevel catch blocks: One in each WndProc and thread initiation routine. Actually, I've just read about set_terminate(), and I'm not so sure about this now. I wonder how exceptions interact with WndProcs. Will they stop unwinding when they reach the end of the applications code, or will they unwind through the guts of Windows, and (maybe?) emerge back in main? Does it matter? Yes. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: package driven postinstall scripts.
On Mon, 2003-03-17 at 06:16, Igor Pechtchanski wrote:
Rob,
Will I be causing grief for you by applying this patch?
Not really, but let's bring your patch and mine closer, so that you could
reuse the good parts of mine (and I could avoid duplicating code). See
below.
Sure.
The install.cc changes I plan to apply regardless, modulo the 'Note
script files as they are installed' 2-liner.
Why not create a proper Installer class? Move all static variables (e.g.,
rebootneeded, package_bytes, etc) into the class? Make initDialog() a
constructor? Make replaceOnReboot{Succeeded|Failed}() private?
I refactored from the top of the file down, making only safe changes,
until I found what I needed to change to track script files. I've no
objection to doing more refactoring, but no immediate reason to either.
And time is always an issue.
As for the Note script files bit, you could add that too, it won't hurt.
Done.
If this goes in, then I can easily throw a package-ordered iterator at
postinstall and solve the root problem.
True. How about merging some functionality from my FileDesc class and
your Script class (at least the == operator)? That way, FileDesc can
simply inherit from Script, add the dependences and the operator, and
that's it...
I'll check this tonight. No basic objection, though the synthetic
operator == may do the right thing at the moment I think.
Also, it might be nice to have a proper Script class... Can you, for
example, rename run_script() into Script::run()? And add a method
extracting the extension into the class?
BTW, do you have to have a vector of Script objects (as opposed to Script
pointers)?
std::vectorScript
package_version::scripts();
If we need virtual behaviour on Script that will have to become
std::vectorScript *
package_version::scripts();
BTW: What was the test case that prompted a need for ordered postinstall
scripts?
Rob
I'm not sure right now, but I think running passwd-grp.sh before
attempting to execute any programs in /bin was one of them...
Cool.
BTW, one other idea I had was a FilterVisitor class that would act as a
wrapper for some other Visitor and only call visit for files that don't
match a pattern... I thought of using it to filter out *.done. It's
pretty orthogonal to the rest of my changes, though...
It's a classic Decorator too. Nice one.
Rob
--
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
signature.asc
Description: This is a digitally signed message part
Re: Partial vs. strict weak ordering (was Re: [PATCH] Postinstallscript ordering in setup - take 3)
On Mon, 2003-03-17 at 06:51, Igor Pechtchanski wrote: STL containers won't choke, as they only need a partial order, AFAIU. The fail simply means it's not a strict weak ordering. They can and will do the wrong thing. because it's not a strict weak ordering, if we have: foo: bar, zonk gam: bar zonk: bar bar: and we insert: bar zonk gam foo we will compare: zonk bar (true) zonk bar gam zonk (false) gam bar (true) gam bar zonk foo gam (false) foo bar (true) gam foo zonk bar which then has foo before zonk, even though foo zonk is true! This is because your ordering requires direct comparison to all members I don't have time right now to go into the maths above, will do so later. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Postinstall script ordering in setup - take 3
On Mon, 2003-03-17 at 07:13, Igor Pechtchanski wrote: And for clarity: my suggested tweak is also not sufficient to provide a weak ordering. Rob Rob, Your suggested tweak provides a total ordering. The unordered(x,y) [!(x y) !(y x)] relation is false for any x != y [since either (x y) or (y x) always holds]. For my example, yes. The problem is when you introduce z. So all equivalence classes have one element: unordered(x,x) is always true. You get transitivity trivially, as unordered(x,y) unordered(y,z) is only true if x == y == z, and then you also have unordered(x,z). But: we break the ordering transitivity. Transitivity x y and y z implies x z [3] y:= foo: gam x:= gam z:= bar: foo both our operators give x y y z !x z (dep)(dep)(alpha) which isn't transitive. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Postinstall script ordering in setup - take 3
On Mon, 2003-03-17 at 07:26, Robert Collins wrote: Transitivity x y and y z implies x z [3] y:= foo: gam x:= gam z:= bar: foo both our operators give x y y z !x z (dep)(dep)(alpha) and !x z for the dependency only operator too. which isn't transitive. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Postinstall script ordering in setup - take 3
On 17 Mar 2003, Robert Collins wrote: On Mon, [EMAIL PROTECTED]:13, Igor Pechtchanski wrote: And for clarity: my suggested tweak is also not sufficient to provide a weak ordering. Rob Rob, Your suggested tweak provides a total ordering. The unordered(x,y) [!(x y) !(y x)] relation is false for any x != y [since either (x y) or (y x) always holds]. For my example, yes. The problem is when you introduce z. So all equivalence classes have one element: unordered(x,x) is always true. You get transitivity trivially, as unordered(x,y) unordered(y,z) is only true if x == y == z, and then you also have unordered(x,z). But: we break the ordering transitivity. Transitivity x y and y z implies x z [3] y:= foo: gam x:= gam z:= bar: foo both our operators give x y y z !x z (dep)(dep)(alpha) which isn't transitive. Rob Umm, I already replied to that in http://cygwin.com/ml/cygwin-apps/2003-03/msg00504.html, but I'll repeat it here: My operator *is* transitive, because of the propagateDependences step... So is yours (since you only changed mine). Neither is transitive without that step. FYI, I couldn't think of a better (linear complexity) way of providing transitivity. Suggestions welcome. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: mknetrel: avoid requiring (fake)root permission
Christopher Faylor [EMAIL PROTECTED] writes: Is there a reason for mknetrel to require (fake)root permissions? Yes. Some packages don't work correctly unless they are installing from root. Ok, but why not use tar to get the permissions right instead of chown? I'll check in something which makes sudo and chown a no-op. Ok, thanks; I'll have a look. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Partial vs. strict weak ordering (was Re: [PATCH] Postinstall script ordering in setup - take 3)
Rob, On 17 Mar 2003, Robert Collins wrote: On Mon, 2003-03-17 at 06:51, Igor Pechtchanski wrote: STL containers won't choke, as they only need a partial order, AFAIU. The fail simply means it's not a strict weak ordering. They can and will do the wrong thing. You're right, of course. My statement above was too general. Let me try again: STL containers that require LessThanComparable (i.e., partial ordering) will not choke. Sorted Associative Containers that require StrictWeakOrdering *will* fail (because the relation I defined isn't). I thought that only LessThanComparable is needed for the sort() function of the list container. Upon rereading http://www.sgi.com/tech/stl/List.html, however, I realized that the sort() function does require a strict weak ordering (but doesn't refer to StrictWeakOrdering, but rather to LessThanComparable). I'm a bit confused now. because it's not a strict weak ordering, if we have: [snip] This is because your ordering requires direct comparison to all members I don't have time right now to go into the maths above, will do so later. Rob I believe I agreed before that the operator I defined is not a strict weak ordering. Now it seems that that's what's needed, even for the list's sort(). I'll need to think on that one some more. Igor P.S. FYI, sort() called with my operator seems to do the right thing, surprisingly, producing a topologically-ordered list... Go figure... -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: nano editor : v.1.2.0 released
- Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 17, 2003 5:21 AM Subject: Re: nano editor : v.1.2.0 released On Sun, Mar 16, 2003 at 11:57:38AM +0100, Pavel Tsekov wrote: On Sun, 16 Mar 2003, Gareth Pearce wrote: A lil slow off the mark ... but here we go... http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1.tar.bz2 http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1-src.tar.bz2 http://www-personal.usyd.edu.au/~gpea0679/nano/setup.hint Uploaded. Don't forget to send an announcement to cygwin-announce. And next time please don't include _update?info?dir in your setup.hint. That gets added automatically if needed. It was misspelled in the setup.hint that was uploaded to sources.redhat.com, resulting in hundreds of messages in my inbox. I didn't catch this immediately because I was out of town. ahh damn - sorry bout that - I was here wondering why i hadnt put it in my 1.1.10 setup.hint - now i remember - too long between releases obviously ... will send announce in a minute or two hopefully.. Gareth cgf
Re: [PATCH] Cleanup: Close handles in script.cc:run()
On Sun, 16 Mar 2003, Robert Collins wrote: Igor Pechtchanski wrote: The attached patch closes the unneeded handles in run() in script.cc. Those handles should be closed according to http://msdn.microsoft.com/library/en-us/dllproc/base/createprocess.asp: lpProcessInformation [out] Pointer to a PROCESS_INFORMATION structure that receives identification information about the new process. Handles in PROCESS_INFORMATION must be closed with CloseHandle when they are no longer needed. Feel free to reject if my understanding of the above is incorrect. Igor == ChangeLog: 2003-03-15 Igor Pechtchanski [EMAIL PROTECTED] * script.cc (run): Close unneeded handles. Applied Rob, BTW, this may not matter, but I agree with Max and Pavel that it's nicer to close the thread handle before the process one. I've submitted the accordingly modified patch in http://cygwin.com/ml/cygwin-apps/2003-03/msg00469.html. If you think it doesn't matter, though, then leave it as-is. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: [PATCH] Cleanup: Close handles in script.cc:run()
On Mon, 2003-03-17 at 10:13, Igor Pechtchanski wrote: Rob, BTW, this may not matter, but I agree with Max and Pavel that it's nicer to close the thread handle before the process one. I've submitted the accordingly modified patch in http://cygwin.com/ml/cygwin-apps/2003-03/msg00469.html. If you think it doesn't matter, though, then leave it as-is. Uhm yeah - I pretty much ignored it as noise :}. Really: HANDLES are refcounted. Destruction order doesn't (cannot) matter for them. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
RE: ExitProcess or exit?
On Mon, 2003-03-17 at 06:52, Gary R. Van Sickle wrote: Well ExitProcess is the windows API exit call. Is there a MSVCRT exit() ? Sure - it'd be hard to justify the CRT part without it! Yeah, I've LCD on my laptop ;}. -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
