* Logging started Thu, 22 Jul 2004 17:23:02 +0000 @1090516983 -dircproxy- You connected @1090516983 -kornbluth.freenode.net- You joined the channel @1090517024 log rolled over, previous log is at http://www.gwydiondylan.org/~housel/irc/dylan-hd @1090517778 Riastradh: can you please spell it? ;-) @1090518088 'I' 't.' @1090518097 [Riastradh!~rias@pool-151-203-221-253.bos.east.verizon.net] ACTION ducks. @1090519025 housel: what? the error messages are identical. are you sure the commit was completed? *sigh* i guess ill have to dive into that python code. @1090519057 or are there any other volunteer? @1090519060 s @1090519203 -dircproxy- You disconnected @1090524420 -kornbluth.freenode.net- phinely (~phinely@128.171.232.51) joined the channel @1090524771 -dircproxy- You connected @1090524810 re @1090524824 Morning all @1090524828 There are newer versions of the script... I guess I should update it @1090524831 morning Peter @1090525073 Would it helpful if I renamed the unsafe copy-bytes to %copy-bytes and changed the order of the parameters of the function and all calls to it to match the other copy-bytes? @1090525136 I don't think either one is unsafe @1090525360 -dircproxy- You disconnected @1090525566 -dircproxy- You connected @1090525635 it's probably best to just stop using the System library unless absolutely necessary @1090525643 This methods from \src\d2c\runtime\dylan aren't unsafe? @1090525645 define method copy-bytes (dest :: , dstart :: , src :: , sstart :: , count :: ) => (); @1090525646 call-out("memmove", void:, ptr: %%primitive(vector-elements, dest) + dstart, ptr: %%primitive(vector-elements, src) + sstart, int: count); @1090525647 System module of the Dylan library I mean @1090525648 end method; @1090525667 oh... you're right, that's unsafe @1090525715 in which case doing what you propose makes sense @1090525775 Which order of parameters do you prefer? I think src, dst is probably better. And it would match fundev. @1090525826 matching fundev (and copy-bytes in common-dylan:byte-vector) is probably more important @1090525851 but dst, src is actually the "preferred" Dylan order @1090525888 If my opinion matters, I prefer the current order. @1090525918 But there's two current orders. :-) @1090525998 It would be best to change them both to dst, src but we'd have to have a flag day, and hunt down all current consumers of Common-Dylan copy-bytes @1090526034 sounds dangerous to me @1090526062 I'm volunteering to do it. I know there's a lot of occurrences, but it's not that many. @1090526084 [Riastradh!~rias@pool-151-203-221-253.bos.east.verizon.net] ACTION hiccups. @1090526086 in both code bases? and in Monday too? @1090526760 commit by housel to fundev: Bug: 7003 @1090526760 Always use the dynamic linking protocol for the glue file since it now @1090526760 contains the export fixups. @1090527723 Actually it looks to me as if the copy-bytes(src, dst) from byte-vector.dylan is not called from any gd code. But changing FunDev to dst, src might be a big chore, plus any clients such as Monday which you mentioned which might be using copy-bytes(dst, src) would have to be changed too. @1090528132 if you check out GD_2_5 as of today, the io library uses copy-bytes(src, dst) in several places now @1090528490 -kornbluth.freenode.net- b0gg1e (~stepn@p3E992613.dip.t-dialin.net) joined the channel @1090528529 -kornbluth.freenode.net- b0gg1e (~stepn@p3E992613.dip.t-dialin.net) left the channel @1090528849 Re. @1090528869 [andreas!andreas@cantor.gwydiondylan.org] ACTION is sitting in the c-base, with Hugh Greene as a visitor. @1090529345 just out of curiosity, why is dst, src the preferred order? isn't it a bit counter-intuitive? @1090529496 Hi Carl! I guess it's because the destination is on the left hand side of an assignment... @1090529536 And Hugh says also because the first argument is usually the one being operated on. @1090529543 I've never found it intuitive for the target to be after the source. I don't know why. @1090529559 hmm. i probably missed some context somewhere @1090529631 map-into! is a good example of another function with the arguments in the right order @1090529665 (sorry, that should be map-into) @1090529809 i don't understand the comment about left hand side, andreas. where's the left hand side in copy-bytes(dst, src)? @1090529833 It's in lhs := rhs. @1090529878 how does that relate to copy-bytes? @1090529923 [cgay!~cgay@ita4fw1.itasoftware.com] ACTION is probably being really dense @1090529939 Well, not at all, except that the order of arguments is the same. @1090530012 hrm. i'm not thrilled about that as a reason to give copy-bytes the unintuitive order of arguments :) @1090530054 It *is* intuitive! :) But I guess this is a little endian against big endian discussion... @1090530094 [andreas!andreas@cantor.gwydiondylan.org] ACTION has problems with newio: there's a "#define foo foo", where foo is an enum value. @1090530097 i'm probably letting English influence my Code thinking too much @1090530126 The Smalltalk approach is nice: mandatory keywords for parameters. @1090530157 for -setter's i see the need for that order (since there may be multiple non-dst arguments) @1090530209 Ok, time for me to go home. Night! @1090530254 g'morning :) @1090530796 andreas, Smalltalk would have the exact same problem. Smalltalk arguments, too, are positional; it just _looks_ like they're keyword arguments. @1090530847 From the Harlequin library-design document: @1090530849 * Functions should take their most important arguments first. @1090530849 * For "copying" functions, the "destination" argument should precede the "source" argument, such as Dylan's replace-subsequence! function. @1090530891 So, somebody wasn't paying attention when it came time to write copy-bytes @1090533314 -kornbluth.freenode.net- brucehoult (~Bruce_Hou@metnet.met.co.nz) joined the channel @1090533649 morning bruce @1090533828 morning Peter @1090533928 hmm .. that wasa fast rsync... @1090533952 Morning Bruce @1090533964 morning! @1090533977 you feel olike answering the guy on gd-hackers? @1090534005 he's not a list memberr, but I let that message through since it didn't look like the rest of the spam @1090534018 I didn't see any mail other than Paul Potts. @1090534067 there was a guy saying Dylan looked interesting but the latest shootout showed it to be slower than Python and Perl and how could that be? @1090534093 of course all *previous* shootout tables haven't included Dylan at all @1090534159 you're doing good work getting Dylan versions of that stuff. I hope you're also comparing the speed to the C and/or C++ versions and letting this chan know when they are significantly different :-) @1090534171 The new version of the matrix benchmark (which hasn't appeared on alioth yet) is only 50% slower than the C version... at least discounting startup time. :-) @1090534204 then that's fine because they discount startup time @1090534229 Not in the default view. I think Brent is going to fix that though. @1090534243 I'm in two minds about the low number of iterations being used @1090534258 on the one hand it makes it hard to see how we're doing against the other fast languages. @1090534293 for the other benchmarks, the main problem is the streams library. I don't know if the newio is going to improve things. @1090534298 but on the other hand if it mashes them all together into 0.02 seconds or something then that probably reflects the reality of the speed difference for most programs @1090534371 Well I'm sure people are open to changing the number of iterations. I think other people want it bumped up too. @1090534385 if it doesn't then we should write the extra ten lines of code (or whatever) to call directly through to an efficient layer such as write() @1090534441 at this point showing that the speed is possible is proabbly mroe important than doing something in 2 lines vs 20 @1090534500 The minus for increasing the number of iterations is that you won't be able to tell how slow the really slow languages are... because they will all the tests will timeout at 30 seconds for that test. The whole complete set of tests X languages takes a long time for the server to run. @1090534607 I should proofread what I type better. @1090534652 I didn't know there was a timeout @1090534675 The tests time out at 30 seconds I think. @1090534749 hmm. 29 tests by 51 language implementations @1090534770 I still haven't received that email from gd-hackers that you mentioned. @1090534772 up to 750 minutes if all test hit the timeout @1090534881 I'm curious how the new-io grafted in from FunDev will perform. But looking at the code, I'm not that optimistic that it will be fast in it's current state. @1090534921 http://www.gwydiondylan.org/pipermail/gd-hackers/2004-July/005146.html @1090534921 dunno @1090534922 that mail was about 12 hours ago @1090534963 Okay, I'll reply to him. @1090535261 I think the streams API should be changed slightly. For example, take @1090535262 read (stream, n, #key on-end-of-stream) => (sequence-or-eof) @1090535264 I don't see a real purpose for the on-end-of-stream key. Why not just return #f?. Then the return type can be tighted up to false-or(). @1090535547 I think read-element should keep the on-end-of-stream key, but for streams such as byte-file-streams or byte-character-file-streams, on-end-of-stream should be set to false. Then the return type for read-element over those types of streams can be tightened up to false-or() or false-or() @1090535658 false-or() isn't a usefully tight type. is wide open @1090535728 yes, but the return type could be made even tigher for byte-file-streams ,etc. @1090535792 I don't know if it is, but read-element is crying out to be inlined, in which case d2c will easily figure out that the return type is type-union(singleton(on-end-of-stream:), stream.element-type) @1090535815 .. just as it already does with the default: value for element @1090535913 I didn't think about it doing that. @1090536187 In the methcall shootout benchmark, did you replace the main() with begin/end to save lines of code? *wondering why you made the change* @1090536280 [housel!housel@cantor.gwydiondylan.org] ACTION notes that debugging in FunDev is easier if you have a main function @1090538183 uhh ... yeah I always code with the main program in begin/end @1090538211 yes, on somethign that is counting lines of code as a goodness measuer it does save one line, but I just prefer it that way anyway :-) @1090539238 Okay... I guess I prefer it the other way. Using begin/end at the top level seems unsanitary to me. hehe @1090539388 well I'm a Pascal guy from way back :-) @1090539437 and all the scripting languages let you just put code at the top level. If we do things right we can show the scripting guys that Dylan is nearly as terse as them, while having C performance @1090539503 the only reason you even need begin/end is so you can use "let". If you don't mind define variable/constant then you can dispense with begin/end as well @1090539684 in d2c it's better to make it a single TLF, too. @1090540351 The list benchmark which uses 's is 100 times slower than C. I'm looking into the problem. @1090541654 looks as if the class needs a lot of work @1090541699 even when d2c knows the exact type (), it still does a GF dispatch on push-last and on the forward-iteration-protocol and so forth @1090541946 commit by phinely to examples: job: 7045 @1090541946 Some imrpovements but no measurable speed increase. @1090541946 The benchmark is still *really* slow. @1090541946 It's losing type info after calling reverse!. @1090541946 I think a lot of methods need to be implemented/sealed for , such as reverse! @1090542083 The last 40% of deque.dylan is commented out. I think a lot of that stuff should be restored. @1090542330 and the functions specialized for instead of @1090544436 re @1090544497 I think using top-level code is fine if you have a single file program, but not when you string hundreds of files together. Then you can't easily tell whether all the top-level code is being evaluated before the main code. @1090544551 I much prefer the Apple Dylan / C/C++ way, where you tell the linker which function to call after evaluating all top-level forms/code. @1090544604 (And there's some reasonable default name, like "main".) @1090545012 hmmm... looks like my newio merge ended up backing out a bunch of changes on GD_2_5... I'll have to go through and put them back. @1090545062 also, the linux build is broken. im looking into that. seems to be some problem with a melange interface. @1090545412 hm. in glibc, _PC_PATH_MAX, among others, is defined in a nameless enum as _PC_PATH_MAX, followed by a "#define _PC_PATH_MAX _PC_PATH_MAX". melange doesnt like this and produces "define constant $_PC_PATH_MAX = $_PC-PATH-MAX;". @1090545466 I think andreas fixed this sort of problem, but I suspect I may have accidentally backed the fix out. @1090545495 seems so. @1090545601 I'll go through every file changed by transaction 542 and look for unwarranted changes @1090545640 -dircproxy- You disconnected @1090547042 -dircproxy- You connected @1090547994 commit by phinely to examples: job: 7045 @1090547994 sealed make and initialize: help performance a little, but not much @1090548216 I'd be surprised if anyone in our group has ever used @1090548237 I guess it's a better fit to that particular task than , but not by much @1090548299 I guess I'll work on fixing @1090548331 if you're allowed to build the same-order list by adding to the front and then calling reverse! (standard Lisp & Dylan idiom) then has no real disadvantage @1090548361 sure. it sould be easy enough. I'm happy to go over it in the weekend too. (that starts in 4 hours from now...) @1090548391 I'll look at the other issues of exporting the names of the concrete implementation classes too @1090548418 maybe even see if I can improve and/or implement limited collections @1090548431 then we can do a relase (we're overdue for one) and say we're using that for the shootout @1090548518 I don't think is exported though it says it should be. @1090548545 How do you "remove each individual item from left side (head) of L2 and append to right side (tail)" with a list easily? @1090548582 you add to the front and then reverse! it @1090548609 of course you can't do that if you want the list to be available to be used in between times @1090548639 where did the comments int he Dylan code come from? Is there an actual spec for the tasks somewhere? @1090548646 I think we should stick with and fix . @1090548652 sure @1090548659 http://shootout.alioth.debian.org/bench/lists/ @1090548716 It's described there. I think I stole the actual comments from the lisp version. @1090548973 The last 40% of deque.dylan is commented out even in the initial version in CVS, so it's hard to track why exactly it was commented out. I assume most of the code that's commented out is correct. It should be specialized on though. I'll hack on it tomorrow or next week. @1090549002 no, if it's OK I'll fix it @1090549034 I know very well what to look for by now @1090549138 brucehoult: I was looking at the limited collections sources. If you're going to work on it, let me know if you'd like any help. @1090549170 Out of curiousity, how are you going to change it? @1090549199 cpage: what would be really good is a set of unit tests based on the actual DRM spec of how limited collections should behave @1090549215 i.e. how substitutable they are, type tests etc @1090549217 The existing testworks stuff doesn't do that? @1090549221 no idea @1090549234 haven't looked at it @1090549243 It's a little hard to tell exactly what it's doing. It would be nice if there were a way to define tests declaratively to make them more transparent. @1090549259 someone *comparing* the exisitng tests against the specs to see if the test are correct would be a good thing :-) @1090549278 and it would be nice to have reference results in cvs so testworks can tell wether there where new failures... @1090549316 Well, I was already looking at them to figure out what it was they were already reporting about limited collections, so I'll keep at that. @1090549324 cool @1090549375 prom: And then we could set up automated build/test cycles on a server that's triggered by CVS commits. :-) @1090549392 cpage: we kinda had that on cantor. but its broken. @1090549400 And it could send mail about changes in results. @1090549401 cpage: ill try to revive it on the new box. @1090549419 cpage: it could also check for bootstrap requirement violation. @1090549423 the way we do it here is a cron job that does a cvs update, and then does a build IFF the cvs update actually found any changed files @1090549442 brucehoult: cantor has a "tinderbox" for it. @1090549450 yeah @1090549456 Adobe had (probably still has) a system where commits go to some kind of holding area and don't actually get committed to shared sources until tests pass or are examined by a human. @1090549468 all I know about that is I've often found cantor with a load average of 20+ as a result of tinderbox @1090549481 yepp, thats tinderbox ;) @1090549504 presumably it doesn't actually check whetehr the previoous incarnation has finished before starting a new one? @1090549528 i havent looked at it yet. @1090549541 And I suppose you'd want it to do that for HEAD and the next release branch? @1090549597 and if tinderbox reports the results anywhere I don't know where that is @1090549607 well. the requirements are different. the current GD_2_5 has to bootstrap with 2.3, 2.3 has to bootstrap with something older (???). then normal builds for both branches. @1090549627 brucehoult: there is a link on the website. @1090549665 prom: I just mean generally speaking, wouldn't you want an automated build/test server to operate on head as well as any major branches? @1090549689 BI->connect(dbname=tbox) failed: could not connect to server: Connection refused at Tinderbox3/DB.pm line 20 @1090549864 cpage: yes, of course. ill try to do that on the new box. @1090549869 Actually, I'm unclear on why HEAD is used the way it is. I'm used to a setup where active development is on a branch and when that branch is "shipped" it is merged into HEAD. @1090549901 cpage: yeah, its a little chaotic. @1090549911 But then, I've been using Perforce, which makes it easier to use branches than CVS, I've been told. @1090550003 What has been the deciding factor on what to put in GD_2_5 vs. HEAD? @1090550168 cpage: i think that depends on how many versions are actively supported @1090550176 cpage: i dont know what was deciding. its messed up. but we can merge 2.5 back to HEAD when 2.4 is out. @1090550183 (after tagging 2.4) @1090550192 I'm more used to development being done on HEAD and then a branch made in order to support a delivery made to a customer @1090550206 yes, thats how it should be. @1090550213 brucehoult: That makes sense when you only have one product and one team working on it. @1090550222 cvs doesnt work very well the other way round. @1090550239 Most of my career has been at companies that have multiple teams working on multiple versions of shared stuff, going into multiple, separate products. @1090550317 And when each ships, they merge their branches into the shared trunk. @1090550330 And then new projects branch off of that. @1090550342 ok, fair enough @1090550368 That assumes an easy way to branch and merge, of course. @1090550400 I haven't looked at branching and tagging in CVS in detail yet. @1090550408 I think that's basically just a way to be able to have several people work on a new feature that isn't ready yet, rather than just having it existing in one developer's uncommitted changes in his checkout @1090550426 The scheme I described? @1090550447 so branches are short-lived and exist in order to develop a specific thing @1090550449 yes @1090550471 Sort of, but the scale is much larger than a single developer working on a single, in-progress feature. @1090550479 that's my point @1090550528 I'm talking about situations where there are three or four teams working on groups of feature sets that don't go into the other products until those products ship and start another product cycle, maybe two years later. @1090550545 everything is fundamentally committed on the trunk once it's completed @1090550586 Yeah, when you put it that way I see your point. @1090550627 that's the reasonable development use of branches @1090550635 and then there's the support use of branches @1090550651 a customer has your program, finds a bug, and wants it fixed @1090550675 If I were setting this up in Perforce, I'd have a GD_2_5 branch and a GD_2_4 (or GD_2_3_x) branch. @1090550678 they don't want the latest version -- or you don't want to give it to them for fee. They want exactly what they already have, except with that one bug fixed. @1090550682 I just found all the unwarranted changes... I'll check the fixes in when the build passes and my house guests leave @1090550684 (iterate as desired) @1090550730 brucehoult: Right. So how does that relate to how you'd set things up in CVS for Gwydion? @1090550765 House guests? Why are you wasting your time on us? :-) @1090550766 rigth now I'd do it exactly how it is @1090550786 Treating 2.3.x and 2.4 as equivalent to head? @1090550790 btw, i think that the whole cvs needs reorganization anyway. we need something that supports moves. and we need to split stuff up into sepparate modules to allow one big unified dylan system. @1090550809 when we decide to ship 2.4 we'll tag that (currently the head) and make a branch for minor bugfix updates @1090550823 and merge gd_2_5 back to the head and develop that on the head @1090550828 yepp @1090550837 prom: Can you explain what you mean by "modules" and "unified dylan system"? @1090550862 so after that point the only things going onto the 2_4 branch will be (pretty much) bitrot fixes @1090550879 brucehoult: I guess. I was thinking the current work on 2.4 *was* maintenance work on 2.3. @1090550880 cpage: well, what i basically mean is that there should be only one instance of every library in cvs. and that, if possible, both systems should share the build system. @1090550904 cpage: which becomes possible thanks to peter, who re-implemented jam in dylan. @1090550922 prom: Oh, your stress is on unifying d2c and FD? @1090550956 cpage: not right now. first, we should do the procedure bruce described and clean up the stuff in its current position. @1090550988 prom: I'm confused. @1090551052 prom: I was just wondering what you meant by "unified dylan system." I wasn't proposing anything. @1090551109 cpage: nothing to be confused about. the idea is to: (1) release 2.4 (2) tag 2.4 (3) create a bugfix branch for 2.4 (4) merge GD_2_5 to HEAD (5) start working on getting rid of multiple versions of libraries and the different build systems. @1090551150 for example, there should be no duim source in the "src" module. this belongs where the rest of duim goes. @1090551196 In fact, isn't "src" named too generically now? @1090551229 yes, it is. i thought about using a different name in this sentence... but it might have been confusing ;) @1090551229 Or should FD be moved into "src"? @1090551259 (Actually, I guess it's too generic even if FD is in there. Libraries have source. :-) @1090551263 i am not yet sure about the exact module layout. it should depend on library dependencies i guess. @1090551291 there will be some libraries that both FD and GD need for bootstrap. like fd streams. @1090551434 maybe "base"/"common", "gwydion-dylan", and "functional-dylan". or something like that. how the build infrastructure should look like for this also needs figuring out. @1090551465 but i think we really dont want several versions of libraries in the repository... @1090551534 "shared"? I think "common" sounds a little too much like "common-dylan", a specific library. @1090551548 Or "bootstrap", if it's really for bootstrapping. @1090551563 building FD with such a source set is also not trivial. many FD libraries do/could work on GD. these shouldnt be in the FD tree, so you can use them with GD without getting the FD source. @1090551593 cpage: "bootstrap" sounds like a good name for the base module. @1090551638 cpage: it could contain basic bootstrapping infrastructure (using a bootstrap binary to compile a dylan impl, use bootstrap c-source to compile....) @1090551646 for all implementations... @1090551673 but i am not sure whether the basic libraries should go there too. @1090551740 cpage: brucehoult: I guess. I was thinking the current work on 2.4 *was* maintenance work on 2.3. @1090551774 well, no. For example I would be intending to work on the collections stuff (including limited collections) on the HEAD @1090551797 that is to say, on 2.3.x -> 2.4 @1090551799 I didn't realize HEAD *was* 2.4 until recently. @1090551808 HEAD is 2.3.x @1090551824 it is 2.3. it will be 2.4. @1090551829 we'll call it 2.4 when we're happy to freeze it as a stable release forever @1090551833 I think it depends on what "is" is. @1090551854 2.5 is a different unstable branch, already in development @1090551879 I might say that if the goal is to develop 2.4, then HEAD is 2.4 in progress. @1090551890 we *could* take 2.3.x and call it 2.4 today. could have at any point in the last several years, I fact @1090551921 ie., there's a difference between having a tag named "GD_2_4" and having committed changes that will eventually be tagged "GD_2_4". @1090551929 perhaps wee've been thinking we should do it until it fully impelment the DRM spec, but that's not going to happen now @1090551961 there is currently no tag or branch called GD_2_4 @1090551969 there *is* a branch called GD_2_5 @1090551984 Right. But you're telling me that HEAD is going to be shipped as 2.4? @1090551990 yep @1090551999 So, HEAD is 2.4, if you see what I mean. @1090552007 standard practice and terminology in the open soruce world @1090552011 right @1090552022 okay @1090552046 odd versions are under active development ("unstable") @1090552072 That seems odd to me (pun intended.) @1090552074 even versions are touched only to fight platform bitrot and/or serious bugs ("stable") @1090552083 cpage: linux does it the same way. @1090552149 I'm used to: #.0 major release, #.# enhancements, #.#.# minor bug fixes and focused but important enhancements. @1090552212 "4.0.1" would be a bug fix to 4.0. "4.1" would be enhancements to 4.0. No meaning for even/odd. @1090552227 Anyway, I get it now. @1090552389 Actually, maybe I don't. Is there a website that explains it? @1090552491 the only real confusion is assuming that "stable" == "good" @1090552499 it just means "not changing" @1090552508 Surely a 2.4 could require fixes? @1090552512 so we have 2.2 as the current stable release @1090552559 I guess the idea is that odd versions are actually "in development"? @1090552588 right @1090552601 I'm used to a scheme where you identify "development" builds apart from "release" builds. But I guess open source has something in between, where you "release" a "development" build. @1090552601 as in "someone could commit something that breaks it at any time" @1090552645 In which case, committing to HEAD makes sense. @1090552801 So, when 2.4 is released ("announced", I guess), it will be tagged, GD_2_5 will be merged into HEAD, at which point it continues to be "unstable", and it will eventually be tagged as a stable GD_2_6, and head builds become version 2.7? @1090552821 right @1090552850 And is it unusual that there's a GD_2_5, or would there be a GD_2_7 and GD_2_9 branch in the future? @1090552851 I'd say that development was started on 2.5 rather prematurely @1090552857 but that's ok :-) @1090552938 And is it unusual for Gwydion to actually branch a stable release to do bug fixes? @1090552988 (I imagine for Gwydion, you'd usually just put fixes in HEAD and let people use that.) @1090553408 so far HEAD has been something that can be bootstrapped from scratch. but once HEAD becomes 2.5 it won't be, at least for a while @1090553425 you'll have to get 2.4 in order to mindystrap @1090553462 .. so we'll have to branch 2.4 for bitrot fixes as OS X 10.4 comes out and breaks our old binaries, or Mandrake 11, or whatever @1090553668 heh @1090553681 I notice you didn't mention Linux :-) @1090553701 Has Mac OS X been particularly problematic? @1090554001 mandrake is linux @1090554096 we've had tons of problems with linux binaries from one distribution not working on other distributions, or versions of the same distribution. @1090554127 it's been especially bad with RedHat and Mandrake, both of which do things their own way @1090559345 -dircproxy- You disconnected @1090562370 -dircproxy- You connected @1090569672 -kornbluth.freenode.net- pritlove_ (~pritlove@port-212-202-174-201.dynamic.qsc.de) joined the channel @1090570261 -kornbluth.freenode.net- ^self (~fn@66.209.66.105) joined the channel @1090570261 -kornbluth.freenode.net- mmc` (~ercmarusk@host31-145.pool80180.interbusiness.it) joined the channel @1090579361 Morning! @1090580072 -kornbluth.freenode.net- pritlove_ (~pritlove@port-212-202-174-201.dynamic.qsc.de) joined the channel @1090583035 re. @1090584024 Moin Gabor! @1090585938 mornin gabor, andreas @1090585962 *sigh* peter seems to have been busy with his guests. @1090587734 Hi prom... @1090591986 -dircproxy- You disconnected @1090592265 -dircproxy- You connected @1090592706 -kornbluth.freenode.net- wm3 (~wm3@sodans.usata.org) joined the channel @1090592721 -kornbluth.freenode.net- wm3 (~wm3@sodans.usata.org) left the channel @1090593075 -kornbluth.freenode.net- wm3 (~wm3@sodans.usata.org) joined the channel @1090594408 how can I eject a CDrom on a sparc-solaris workstation? @1090594449 there should be a menu option in the windowing environment @1090594457 (IIRC) @1090594544 found the "eject" command, it worked :-) @1090594775 commit by housel to src Makegen,1.24.2.4,1.24.2.5: Job: gd25 @1090594775 * Restore GD_2_5 changes that were somehow removed during the gd-2-3-newio @1090594775 merge, including some RCS header removals. @1090594775 * Remove other remaining RCS headers. @1090594775 commit by housel to src: Job: gd25 @1090594776 * Restore GD_2_5 changes that were somehow removed during the gd-2-3-newio @1090594778 merge, including some RCS header removals. @1090594780 * Remove other remaining RCS headers. @1090594936 ah! yeeha! ;) @1090594979 ill update, re-strip configure.in and continue with my cleanups. @1090596042 hm. i think ill remove stuff caring about d2c_target. this is not stupid gcc that can only target one kind of system. @1090596119 (its not used anyway because cross compilation is not really implemented.) @1090596379 Ok, I'll go home. See you! @1090596610 cya @1090597440 -dircproxy- You disconnected @1090600709 hm. i still have this _PC_PATH_MAX problem. melange just doesnt get the enum that is used to define it. or the fact that there is a macro "#define _PC_PATH_MAX _PC_PATH_MAX". @1090602425 -kornbluth.freenode.net- badonaway (KCXYCL@skoubye.dsl.xmission.com) joined the channel @1090604033 -dircproxy- You connected @1090604106 I fixed that once... but maybe it only got fixed on HEAD and on the branch @1090604209 housel: yes, that sounds plausible. ill try a 2.3 melange. @1090604507 -kornbluth.freenode.net- sprout (~Snak@drop242.drizzle.com) joined the channel @1090604677 yeah, works. @1090604788 I think it's the change made 2003-10-31 that fixed it @1090604804 but there have been a lot of melange improvements made on HEAD that need to be merged @1090604867 yeah. but the branch structure makes merging a little more difficult... @1090604939 true @1090605257 hm. the last merge seems to have been HEAD_20031018_merged. @1090605337 you want to do another one? @1090605351 ill try. @1090605788 hm. a lot of work. but its a lot less when ignoring platform/. which, i think, could be removed from GD_2_5. @1090605899 why? @1090605984 housel: because it does not belong to the GD system itself. @1090606083 that needs to be discussed perhaps @1090606098 housel: with all that FD source in cvs, we will have to categorize this in some meaningful matter. separating gui code is a means for doing that. @1090606137 but we can't do to code until it becomes cross-platform @1090606199 housel: yes. but i wonder if anybody really uses gd-duim. especially from GD_2_5. @1090606238 andreas is developing the gtk2 backend in the 2.5 branch... @1090606298 housel: yes, but he liked the idea of moving this to a different place. @1090606579 that's a problem for later... could you do the merge without platform/? or maybe just melange? @1090606635 yes. but merging the rest later will be a little bit harder because you have to merge the subdirectories one-by-one. @1090606780 hm. i could also try merging GD_2_5 to a HEAD checkout. then we could tag and branch off 2.4. and merge GD_2_5 to HEAD. this would allow doing bugfixes in GD_2_4 and merging them normally. @1090606850 BTW the usual convention is that branches are lowercase and use '-' separators, while tags are uppercase @1090606878 so it should be gd-2-4 @1090606975 there are more tags in CVS using underscore as a separator. but apart from that unimportant detail, yes. @1090606998 ill see how difficult it would be. @1090607332 hm. that doesnt look too hard. @1090607358 a lot of conflicts, but a good part of them is caused be keyword tag removals. @1090607366 by even @1090607423 -kornbluth.freenode.net- rhashem (~gtg990h@ip68-100-67-72.dc.dc.cox.net) joined the channel @1090609352 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090610736 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090610786 i made a quick merge. i guess i still missed something, but merging GD_2_5 to head soon looks doable. @1090610913 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090610932 good @1090610982 er, let's try this again. Sorry for the outage folks; looks like JohnCompanies temporarily reverted cl.net to an old image. No clue why. @1090611136 I'll commit my outstanding changes in my HEAD working copy and create the gd-2-4 branch, ok? @1090611166 or maybe we should ask everyone else first if they have any changes to commit @1090611265 hm. yeah, asking is better. ill need a while for a clean, understood merge anyway. i dont think anybody will have changes over the whole tree, so the conflicts i would get later should be ok. @1090611406 I'll send a message to gd-hackers @1090611410 yepp. @1090614842 -kornbluth.freenode.net- phinely (~phinely@128.171.232.51) joined the channel @1090615751 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090615938 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090615961 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090615984 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090616001 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090616047 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090621459 Riastradh: in case you're still interested, a second-stage bootstrap of FunDev on linux requires 246797 lines of Dylan source @1090621484 re @1090621485 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090621525 -kornbluth.freenode.net- lisppaste (~lisppaste@common-lisp.net) joined the channel @1090621626 A full Windows "internal" release compiles 669317 lines of Dylan source @1090624961 [prom!~prom@217.13.206.33] ACTION rests his head on his laptop. cvs could suck a star back out of a black hole. @1090625342 quite @1090626806 -kornbluth.freenode.net- phinely (~phinely@128.171.232.51) joined the channel @1090632249 -dircproxy- You disconnected @1090634957 -dircproxy- You connected @1090635182 commit by housel to fundev: Bug: 7003 @1090635182 Still more goodies from the Perforce jam 2.5 Jambase. @1090635254 commit by housel to fundev: Bug: 7003 @1090635254 Various fixes, and an implementation of the DylanLibraryCSources rule. @1090635306 commit by housel to fundev: Bug: 7003 @1090635306 One C library per line, please. @1090635629 -dircproxy- You disconnected @1090644531 -dircproxy- You connected @1090657303 commit by bruce to examples: Job: 7045 @1090657303