00:04.36 |
``Erik |
IriX64 ... .exe files are PF executables, fbsd
uses ELF or QMAGIC executables... there's no way it can
run.. |
00:05.49 |
IriX64 |
im from missourrii , show me. |
00:06.00 |
``Erik |
... go hop on a linux or freebsd box |
00:06.04 |
``Erik |
and try to run a windows executable. |
00:06.07 |
``Erik |
without using an emulator. |
00:06.12 |
``Erik |
then you'll be shown |
00:06.41 |
IriX64 |
$ uptime |
00:06.41 |
IriX64 |
<PROTECTED> |
00:06.41 |
IriX64 |
IriX64@FthrNtr ~/brlcad-7.8.4 |
00:06.41 |
IriX64 |
$ |
00:06.51 |
IriX64 |
this is on a windows machine. |
00:07.29 |
IriX64 |
crap should have pastebinned, sorry.
:( |
00:07.32 |
``Erik |
<PROTECTED> |
00:07.35 |
``Erik |
not a windows machine |
00:07.36 |
``Erik |
:D |
00:08.26 |
``Erik |
<PROTECTED> |
00:08.33 |
``Erik |
also not a windows machine... :D |
00:08.39 |
IriX64 |
:) |
00:08.57 |
``Erik |
you can tell by the uptime... O:-) |
00:09.07 |
IriX64 |
you can tell mine by the short time its been
up. :) |
00:09.13 |
Maloeran |
Tsk, such high uptimes are a sign that you
don't overclock enough! |
00:09.20 |
IriX64 |
heh |
00:10.30 |
``Erik |
heh, these are machines meant for
reliability... |
00:11.02 |
``Erik |
<PROTECTED> |
00:11.17 |
Maloeran |
Oops |
00:11.22 |
Maloeran |
<PROTECTED> |
00:11.27 |
``Erik |
hearing an old woman bark "who do I have to
gum to get a refill?" is disturbing |
00:12.29 |
``Erik |
(was on simpsons... mal, urban dictionary for
'gumjob' ... O:-) ) |
00:12.30 |
Maloeran |
I think I don't want to look up other meanings
of the verb "to gum" that I'm not familiar with |
00:12.51 |
``Erik |
perhaps a wise move |
00:13.09 |
IriX64 |
juciy fruit? :) |
00:13.36 |
IriX64 |
thats chewing gum |
00:14.13 |
``Erik |
doublemint, yo, hook me up with some hot twins
;) |
00:14.27 |
IriX64 |
heh sen sen |
00:17.32 |
IriX64 |
copy pretty.exe pretty.a pretty.a
<---- still runs |
00:18.02 |
``Erik |
... on windows, yes. |
00:18.06 |
``Erik |
because it's still a PF binary... |
00:18.10 |
``Erik |
it is NOT an elf binary |
00:18.26 |
``Erik |
here, let me send you an ELF binary, lets see
if you can run it... |
00:18.41 |
IriX64 |
was producedto be no matter what its
called. |
00:19.11 |
IriX64 |
quite right |
00:19.30 |
IriX64 |
rt11 rawks ``Erik. :) |
00:19.39 |
IriX64 |
RT11 get it right. |
00:20.09 |
``Erik |
aaaaand you know this from experience? no?
thought so :D |
00:21.08 |
IriX64 |
Why can't i produce an ELF binary and call it
whatever i want? |
00:21.15 |
Maloeran |
You can't produce ELF binaries on windows.
Windows uses that MZ thing |
00:21.41 |
IriX64 |
gcc cannot produce elf binaries? since
when |
00:21.42 |
IriX64 |
? |
00:21.57 |
Maloeran |
gcc produces binaries that are appropriate for
your platform, unless you cross-compile |
00:22.06 |
``Erik |
uh, if you install a normal gcc on windows, it
cannot produce elf binaries |
00:22.08 |
Maloeran |
And when you cross-compile, you can't execute
the binaries meant for the target platform |
00:22.41 |
Maloeran |
IriX64, just install Linux and play around
with it |
00:23.05 |
IriX64 |
http://www.pastebin.ca/368340 |
00:23.33 |
``Erik |
... yes... and? |
00:23.47 |
IriX64 |
Maloeran: illegal instruction trap, handalable
without bailing? |
00:24.28 |
Maloeran |
You can catch the SIGILL signal, yes |
00:24.53 |
Maloeran |
SIGKILL and SIGSTOP are the only two you can't
catch |
00:24.57 |
IriX64 |
and try to find a cygwin entry point ie your
MZ thing |
00:25.33 |
IriX64 |
exe is huge but 200gig drive here
*shrug* |
00:26.07 |
Maloeran |
I really recommend to repartition and install
Linux, you'll get some good and more varied experience |
00:26.36 |
IriX64 |
had linux on vmware. |
00:26.43 |
Maloeran |
Real Linux ;) |
00:26.59 |
IriX64 |
its vmware thats not real ;) |
00:27.35 |
``Erik |
(or fbsd, or nbsd, or obsd, or dragonfly, or
minix, or zetaos, or ...) |
00:27.59 |
``Erik |
solaris-x86, ... |
00:28.18 |
Maloeran |
He'll suffer less with Linux |
00:28.29 |
``Erik |
I'd disagree |
00:28.37 |
``Erik |
YOU suffer less with linux because you're
familiar with linux |
00:28.44 |
``Erik |
just like irix suffers less with windows right
now |
00:28.59 |
``Erik |
man, that sentence sounded dirty, irix64 needs
a new nick o.O |
00:29.20 |
Maloeran |
I think there are Linux distributions far
friendlier than FreeBSD... |
00:29.33 |
Maloeran |
And he's not quite ready for Gentoo or Linux
from scratch :) |
00:29.43 |
``Erik |
there're bsd distributions far friendlier than
fbsd, too |
00:29.46 |
``Erik |
like pcbsd |
00:29.56 |
Maloeran |
Ah, never heard of it |
00:30.15 |
IriX64 |
http://www.pastebin.ca/368347
<--this is the only piece of code ive ever written. :P |
00:31.12 |
``Erik |
wow, there is so much wrong with
that |
00:31.14 |
``Erik |
*boggle* |
00:31.18 |
``Erik |
O:-) |
00:31.36 |
Maloeran |
Well, at least it's C and not Javascript or
Basic |
00:31.54 |
``Erik |
it's sorta C |
00:32.07 |
IriX64 |
C- i call it. |
00:32.49 |
``Erik |
would that even compile with the args messed
up? heh |
00:33.02 |
Maloeran |
I think it will compile with
warnings |
00:33.19 |
Maloeran |
Well, assuming you got a compiler with conio.h
and kbhit() of course |
00:33.35 |
``Erik |
those're lib functions, not compiler
things... |
00:33.50 |
brlcad |
reminds me of an old dos program I wrote a
really long time ago |
00:34.30 |
``Erik |
backward args, poor logic path, magic numbers,
no indentation, etc? :D |
00:34.31 |
``Erik |
*duck* |
00:34.33 |
brlcad |
compiler too.. they're both int-castable
values and main is in the compiler's realm |
00:39.26 |
Maloeran |
I never quite understood that one |
00:39.46 |
``Erik |
*shrug* probably just weren't in the sym
map |
00:40.11 |
Maloeran |
It's a low-level interrupt, can't get any
closer to the hardware |
00:40.37 |
``Erik |
dos may've caught the interrupt, didn't
recognize it, and did an iret without pushing it |
00:40.37 |
Maloeran |
Eh no :), IriX64's archaic code brings back
memories, old stuff I never figured out and still don't |
00:40.39 |
IriX64 |
kb too |
00:41.00 |
IriX64 |
getvect setvect how much fun is
that. |
00:41.41 |
IriX64 |
btw ill have you know pretty runs just
fine. |
00:45.03 |
Maloeran |
So how's that OS coming along, Erik?
:) |
00:45.25 |
IriX64 |
http://irix64.spaces.live.com/?_c11_PhotoAlbum_spaHandler=TWljcm9zb2Z0LlNwYWNlcy5XZWIuUGFydHMuUGhvdG9BbGJ1bS5GdWxsTW9kZUNvbnRyb2xsZXI%24&_c11_PhotoAlbum_spaFolderID=cns!BFB9E7E9DA2BD02D!113&_c11_PhotoAlbum_startingImageIndex=15&_c11_PhotoAlbum_commentsExpand=0&_c11_PhotoAlbum_addCommentExpand=0&_c11_PhotoAlbum_addCommentFocus=0&_c=PhotoAlbum&_c02_owner=1 |
00:45.42 |
IriX64 |
i *wont do *that again sheez |
00:46.45 |
``Erik |
haven't touched it in a while, mal, too much
other stuff to do :( |
00:47.04 |
IriX64 |
``Erik you write os? |
00:47.23 |
``Erik |
in the grand scheme of things, that os is
awfully low on the priority list |
00:47.45 |
IriX64 |
personal project then? |
00:47.57 |
``Erik |
yeah |
00:48.12 |
``Erik |
both my own os and most of my work with fbsd
are personal projects |
00:48.30 |
IriX64 |
Based on or is this a new idea? |
00:49.39 |
``Erik |
um, inspired by old lispos, with some other
equally ancient ideas like automatic parallelism and distribution,
stateful system coherency, etc |
00:50.57 |
Maloeran |
An OS with its own synchronisation mechanisms
and interfaces geared up towards cluster processing could be
amusing |
00:52.40 |
Maloeran |
IriX64, you seem to be motivated and have free
time, you should pick up a C book and burn a Linux CD |
00:52.59 |
``Erik |
or a bsd cd, or a solaris cd, or a zeta cd, or
a ... |
00:53.10 |
IriX64 |
if any body cares, that Gesr thing is a paper
tape reader/punch replacement for an industrial computer. |
00:54.42 |
Maloeran |
Or a Linux CD, and embark in a grandiose and
wondrous adventure towards knowledge, the infinity and
beyond! |
00:55.38 |
IriX64 |
can't wait till my spirit take
flight. |
00:57.29 |
``Erik |
<-- also stunted for learning basic as his
first programming language :D |
00:57.56 |
IriX64 |
fortran here |
00:58.08 |
IriX64 |
WatIV |
00:58.14 |
``Erik |
obviously not, irix. |
00:58.32 |
``Erik |
:D |
00:58.41 |
IriX64 |
WatIV is obvious? |
00:58.53 |
IriX64 |
:) |
01:01.05 |
Maloeran |
Ouch Erik, Basic. I'm sorry, I didn't
know... |
01:02.25 |
IriX64 |
need to tend to life. l8r. |
01:02.41 |
Maloeran |
I have used C and assembly rather exclusively,
if you omit the attempts at getting used to other
languages |
01:16.49 |
louipc |
I recommend archlinux :D |
01:17.51 |
louipc |
oh he left :P |
01:18.46 |
Maloeran |
Ubuntu is supposed to be very friendly though
I heard some horror stories |
01:19.23 |
Maloeran |
A friend had an IDE controller or something
that it didn't like somehow, and it would destroy cdrom drives
systematically |
01:19.28 |
louipc |
horror or stories of discomfort? |
01:19.34 |
louipc |
that's horror |
01:22.12 |
louipc |
I just found it very uncomfortable |
01:23.50 |
``Erik |
maybe you put the cd in the wrong
place? |
01:24.25 |
louipc |
hah hah |
01:28.00 |
Maloeran |
for cutting, rather |
01:33.54 |
Twingy |
guess what |
01:34.05 |
Twingy |
time to go running |
02:52.24 |
*** join/#brlcad SWPadnos
(n=Me@dsl245.esjtvtli.sover.net) |
05:51.50 |
*** join/#brlcad justin_
(n=justin@74.92.144.217) |
07:17.12 |
Maloeran |
brlcad, a stupid question, but if I make
changes to librt's nmg_* functions, how can I test? :) |
07:17.42 |
Maloeran |
Also, may any fix to have triangles face the
proper pay prove useless with the coming opennurbs
updates? |
11:31.27 |
*** join/#brlcad tofu
(n=sean@bz.bzflag.bz) |
11:34.04 |
*** join/#brlcad archivist
(n=archivis@host217-35-76-52.in-addr.btopenworld.com) |
12:50.07 |
*** mode/#brlcad [+o brlcad]
by ChanServ |
13:34.23 |
CIA-7 |
BRL-CAD: 03brlcad * 10brlcad/autogen.sh: make
sure we can restore COPYING/INSTALL when automake decides to ignore
our umask |
13:56.13 |
brlcad |
Maloeran: easiest would probably be to take
one of the converters, e.g. g-stl or g-nmg and test |
13:57.34 |
brlcad |
and no, I don't think it'd be useless..
opennurbs has a *long* way to go to prove that it can replace nmg
outright -- for now it's just going to be a new primitive,
replacing tessellations would be something to try after
that |
14:42.22 |
*** join/#brlcad cad59
(n=c128fb04@bz.bzflag.bz) |
14:45.21 |
*** join/#brlcad cad59
(n=c128fb04@bz.bzflag.bz) |
15:39.50 |
CIA-7 |
BRL-CAD: 03erikgreenwald *
10brlcad/src/adrt/libtie/define.h: use common.h to wrap
brlcad_config.h for external apps |
16:06.08 |
CIA-7 |
BRL-CAD: 03jlowenz *
10brlcad/src/librt/g_brep.cpp: Begin implementation of brep plot
routine. start with coarse mesh from openNURBS. |
16:52.18 |
CIA-7 |
BRL-CAD: 03jlowenz *
10brlcad/src/librt/g_brep.cpp: Begin implementation of brep plot
routine. actually use vlist to draw mesh. |
17:06.25 |
brlcad |
shibby |
17:23.26 |
*** join/#brlcad IriX64
(n=mario_du@bas3-sudbury98-1168049077.dsl.bell.ca) |
17:38.04 |
IriX64 |
http://www.spaces.live.com/IriX64 |
18:01.57 |
CIA-7 |
BRL-CAD: 03erikgreenwald *
10rtcmp/adrt/adrt.c: fill in ray origin and dir on shoot. Set nmg
'silent' flag. dup path. |
19:32.43 |
CIA-7 |
BRL-CAD: 03brlcad *
10brlcad/src/adrt/libtie/define.h: common.h should always be
included before any system headers |
19:53.03 |
IriX64 |
``Erik, so you admit I can produce ELF
binaries on my toy windows systen ? :P |
19:53.11 |
IriX64 |
system too. |
19:54.37 |
``Erik |
if you were to install a real ELF
crosscompiler and knew how to use it, sure |
19:54.46 |
``Erik |
... |
19:54.50 |
``Erik |
that's not an elf binary |
19:54.59 |
``Erik |
do you have "file" installed? it's a program
that tells you about a specified file |
19:55.02 |
IriX64 |
is now :) |
19:55.18 |
``Erik |
it'll identify binaries and what format they
are |
19:55.48 |
``Erik |
$ file /usr/brlcad/bin/rt |
19:55.51 |
``Erik |
/usr/brlcad/bin/rt: ELF 64-bit LSB executable,
AMD x86-64, version 1 (FreeBSD), dynamically linked (uses shared
libs), not stripped |
19:55.56 |
IriX64 |
I have it. should use it , yes? :) |
19:56.03 |
``Erik |
$ file /usr/brlcad/bin/rt |
19:56.06 |
``Erik |
/usr/brlcad/bin/rt: Mach-O executable
ppc |
19:56.41 |
``Erik |
you'll probably see something about a windows
PE executable |
19:56.50 |
Maloeran |
The extension does not define what a file is,
it's used by certain environments to decide the default actions
when for the files |
19:57.02 |
Maloeran |
when interacting* with the files |
19:57.20 |
``Erik |
certain stpid environments, good ones look at
file magic *cough* |
19:57.48 |
Maloeran |
File magic is far slower |
19:58.05 |
``Erik |
yes, .0001 seconds instead of .000001 seconds,
ohs noes |
19:58.22 |
IriX64 |
$ file mged.exe |
19:58.22 |
IriX64 |
mged.exe: MS-DOS executable PE for MS Windows
(console) Intel 80386 32-bit |
19:58.22 |
IriX64 |
IriX64@FthrNtr /usr/cygcad/bin |
19:58.46 |
Maloeran |
It's far slower than that, really. There are
WMs and dekstops which run file for every file of a directory when
you view it |
19:58.59 |
Maloeran |
And it crawls terribly, opening every file and
checking its format |
19:59.36 |
``Erik |
heh, nautilus does that, I think, and caches
results... it even extracts images to provide thumbnails iirc
*shrug* |
20:00.35 |
Maloeran |
rxvt is all the gui I need anyhow :) |
20:01.17 |
Maloeran |
I used both elelfm2 and gentoo for some time,
I stopped using both when some bugs ( in *both* ) made the apparent
selection be different from the real selection, causing me to
delete files I did not want to |
20:02.09 |
``Erik |
if you're too lame to delete files from the
command line, use mc, it sucks less :D |
20:02.43 |
Maloeran |
Eh, I always use the command line now, I
finally got used to it |
20:10.22 |
IriX64 |
how do you camman a line? :) |
20:10.26 |
IriX64 |
command too |
20:10.43 |
Maloeran |
With a sharp ruler |
20:10.57 |
IriX64 |
.me bows to Maloeran :P |
20:11.03 |
IriX64 |
err |
20:13.28 |
IriX64 |
err Maloeran ordered my ammunition
confiscated. :) |
20:25.29 |
Maloeran |
Just install some Unix, you'll learn quite a
bit. Pick Linux or FreeBSD, it will determine who of us two you can
ask questions to |
20:25.50 |
IriX64 |
haaha I get it. thanks. |
20:30.15 |
``Erik |
neat, adrt gives radically wrong answers, I
must be using it wrong |
20:31.34 |
Maloeran |
That might be why it seems so slow |
20:31.46 |
``Erik |
http://paste.lisp.org/display/37285 |
20:32.24 |
Maloeran |
Cool |
20:32.44 |
``Erik |
'firing' in the middle is origin ->
direction |
20:32.58 |
``Erik |
librt is first, then some adrt noise, then
adrt results |
20:34.07 |
``Erik |
the massive jitter on adrt's x/y is what
concerns me at the moment, though the distances on the r212 region
are kinda concerning |
20:34.50 |
IriX64 |
``Erik? thats an rt shot? admitting my
ignorance here. |
20:34.59 |
``Erik |
sorta, yes |
20:35.10 |
IriX64 |
how's it done? |
20:35.10 |
``Erik |
it's a partition biulding shot using two
engines |
20:35.12 |
``Erik |
uhhhh |
20:35.15 |
``Erik |
software? :D |
20:35.18 |
IriX64 |
heh ty. |
20:35.25 |
``Erik |
if you want to do a single ray by hand, check
out "nirt" |
20:35.37 |
Maloeran |
I like these numbers. I think my code can fit
well with that kind of accuracy |
20:35.47 |
IriX64 |
never played with all the gadgets but i think
ill experiment. |
20:36.06 |
``Erik |
hahaha, well, it's inexcusable accuracy :D I'm
either doing osmething wrong, or tie is busted |
20:36.59 |
``Erik |
the z is all correct, I think |
20:37.58 |
IriX64 |
get syntax errors in fron of all the BC_ stuff
in configure. |
20:38.03 |
``Erik |
but the 1.2% deviation is ... wow |
20:38.03 |
IriX64 |
front too. |
20:38.12 |
``Erik |
aclocal -I ./m4 |
20:38.18 |
``Erik |
or ./autogen.sh |
20:38.45 |
IriX64 |
./autogen.sh works but you *should be able to
run aclocal without switches. |
20:39.13 |
IriX64 |
the stuff is there but has syntax
errors |
20:40.24 |
``Erik |
the early autoconf'd version of brlcad didn't
need that, talk to brlcad about it *shrug* |
20:40.36 |
IriX64 |
ty |
20:46.19 |
``Erik |
<PROTECTED> |
20:46.19 |
``Erik |
<PROTECTED> |
20:46.19 |
``Erik |
<PROTECTED> |
20:46.22 |
``Erik |
nice... :( |
20:47.07 |
Maloeran |
That's the source of the problem? |
20:47.15 |
``Erik |
I believe so |
20:47.27 |
Maloeran |
It's surely to avoid divides by zero |
20:47.34 |
``Erik |
since my ray dir is defined as 0,0,1 |
20:47.53 |
``Erik |
it gets used as TIE_PREC,TIE_PREC,1 |
20:49.17 |
``Erik |
0.008435 |
20:49.42 |
``Erik |
which correlates |
20:49.55 |
Maloeran |
This is all good stuff. The more inaccuraries
you find there, the least worse my code will seem |
20:50.00 |
``Erik |
hah |
20:52.29 |
``Erik |
it's visually tolerable, but not geometric
analysis tolerable... I think it'll need to be fixed :/ |
20:55.19 |
*** join/#brlcad Maloeran
(n=maloeran@glvortex.net) |
20:55.27 |
Maloeran |
I hate Ctrl+Alt+Backspace! |
20:56.30 |
IriX64 |
http://www.pastebin.ca/369427
< -- a run of the behavious i described. |
20:56.40 |
IriX64 |
behaviour too. |
20:57.51 |
Maloeran |
Who would ever create a shortcut that kills X
made of keys that one could very well use in rapid succession or
simultaneously |
20:59.15 |
``Erik |
alt control delete? |
20:59.35 |
``Erik |
how is that so easy to hit? O.o |
20:59.35 |
Maloeran |
At least that does not kill windows |
20:59.47 |
Maloeran |
Ctrl+Alt+Backspace kills X
instantly! |
20:59.50 |
``Erik |
also; run irc in screen, so'z it won't
disconnect |
21:00.04 |
``Erik |
yes, alt+ctrl+backspace is the
OMFGKILLX!!~! |
21:00.57 |
``Erik |
ahhh, the days of fullscreen game programming
when sdl was flakey :D |
21:01.04 |
Maloeran |
I frequently type with the right hand, the
left hand holds ctrl+alt to soon switch desktop |
21:01.20 |
Maloeran |
I make a typo, hit backspace, and boom. It
happens about once every two weeks |
21:01.36 |
``Erik |
hm, the solution is simple: quit doing
that. |
21:04.12 |
IriX64 |
errr or undo it (duck) |
21:06.46 |
brlcad |
IriX64: there are lots of things wrong with
that |
21:06.53 |
brlcad |
in regards to "15:37 * IriX64 wonders whats
wrong with aclocal, autoheader, autoconf, automake
sequence" |
21:07.12 |
brlcad |
autoreconf doesn't do just that
either |
21:07.41 |
IriX64 |
but you should be able to do that
no? |
21:07.47 |
brlcad |
nope |
21:07.53 |
IriX64 |
really? |
21:08.07 |
brlcad |
well, at least no if you also want to expect
it to work |
21:08.09 |
IriX64 |
it used to work on 7.6.0 |
21:08.19 |
IriX64 |
and 7.6.2 |
21:08.20 |
brlcad |
you got lucky |
21:08.25 |
IriX64 |
twice? |
21:08.30 |
brlcad |
it *can* work |
21:08.37 |
IriX64 |
details plz. |
21:08.39 |
brlcad |
but it doesn't mean it *will* or should
work |
21:08.52 |
IriX64 |
not a problem then? |
21:09.29 |
brlcad |
it's a problem with what you're doing, but not
a problem with how it's set up |
21:09.45 |
IriX64 |
wrong sequence? |
21:09.52 |
brlcad |
yes |
21:09.55 |
brlcad |
and wrong parameters |
21:10.04 |
IriX64 |
ty. |
21:10.13 |
IriX64 |
Ill study up on it. |
21:10.47 |
IriX64 |
right now i'm listening to Romeo and Juliet by
Dire Straits. :) |
21:11.00 |
brlcad |
read autogen.sh, look for a section entitled
MANUAL_AUTOGEN FUNCTION |
21:11.11 |
IriX64 |
ty i will. |
21:11.49 |
brlcad |
there it lists the steps you have to take if
you want to do it by hand, though even that is slightly misleading
as those steps apply to non-recursive configurations (and the next
release will have recursive) |
21:12.21 |
IriX64 |
automake is non-recursive ? :P |
21:12.25 |
brlcad |
you should read the header to autogen.sh too
-- says what it does in a summary |
21:12.33 |
IriX64 |
ty |
21:12.39 |
brlcad |
automake is neither recursive or
non-recursive |
21:12.50 |
IriX64 |
cmon it delves |
21:13.18 |
IriX64 |
calls itself too. |
21:13.35 |
brlcad |
make recurses and calls itself |
21:13.43 |
brlcad |
automake just processes a bunch of files
passed to it |
21:14.58 |
IriX64 |
look for .am ahh found it engage operate on it
mode done look for another, ah hell its a directory
sigh.... |
21:16.18 |
IriX64 |
then translated it to vms dcl. |
21:16.55 |
brlcad |
you have a lot of gillichisms in you |
21:17.15 |
IriX64 |
yeah hard to unlearn you know, but i'm
trying. |
21:17.45 |
brlcad |
heh, i don't think that means what you think
it means |
21:17.54 |
IriX64 |
like typing with two fingers sigh, ill never
beat that. |
21:17.58 |
brlcad |
did you read autogen.sh yet? |
21:18.11 |
IriX64 |
you meant now, hold on... |
21:18.24 |
Maloeran |
Typing with 2 fingers? Impressive, you are
quite fast at it |
21:19.25 |
IriX64 |
err maunual_autogen_function not there case
sensitivity turned off same. |
21:19.50 |
IriX64 |
ty Maloeran. |
21:19.53 |
brlcad |
then you're not using the newer autogen.sh
that you were supposed to have downloaded a couple days
ago |
21:20.07 |
IriX64 |
wrong tree just a sec... |
21:20.14 |
brlcad |
look for just manual then |
21:20.31 |
brlcad |
and still, the header is the same in both,
read the intro |
21:20.46 |
brlcad |
after the legal junk is an
explanation |
21:22.38 |
IriX64 |
look its not there i tried searching four
trees and the scipt i downloaded. |
21:23.22 |
IriX64 |
and i checked for typos in my search string
:) |
21:24.30 |
IriX64 |
ill just rely on autogen. |
21:24.51 |
IriX64 |
is the other method deprecated? |
21:29.23 |
brlcad |
which is pretty much the response of everyone
until they learn how to use them right |
21:29.52 |
brlcad |
there are reasons why the tools are the way
that they are, for better or worse, and seeing why they are the way
they are only comes with time |
21:30.32 |
brlcad |
the only way you can do better really is by
changing a lot of assumptions, requirements, or increasing the
baseline |
21:30.59 |
brlcad |
otherwise, when used as documented, they work
better than any alternatives |
21:31.21 |
brlcad |
that doesn't mean easy on the developer, but
it does result in an interface that requires the least of ones
users |
21:31.43 |
brlcad |
IriX64: in your case, you also apparently
trying to learn how the tools themselves work for some
reason |
21:31.54 |
IriX64 |
curiousity. |
21:32.05 |
Maloeran |
IriX64, go learn to code, it's more
interesting ;) |
21:32.12 |
brlcad |
I can't fathom why you'd *want* to try to run
individual commands when there are two interfaces provided that
work correctly |
21:32.12 |
IriX64 |
comparing to what I am used too. |
21:32.31 |
brlcad |
but that's not even practical knowledge for
the most part.. running the autotools steps like that |
21:32.45 |
IriX64 |
Thanks maloeran I need much knowlewdge care to
teach? :) |
21:33.08 |
brlcad |
it's not even a valid comparison to other
build environments, as that's not even the documented use |
21:33.14 |
IriX64 |
sorta like being a backyard mechanic
brlcad. |
21:33.37 |
Maloeran |
We can't "teach", but we can answer questions,
Grab K&R, the C programming langyage holy bible, or some online
guide |
21:33.49 |
IriX64 |
will do. |
21:34.21 |
IriX64 |
God created me with a leaky valve, I'll be
right back. |
21:35.11 |
brlcad |
if you really want to learn how it works under
the hood, study autogen.sh in detail -- read it until you
understand it one line at a time |
21:36.12 |
brlcad |
autogen.sh only exists because of
versioning/compatibility flexibility issues with the autotools over
their years of existence, it's a wrapper around the documented way
that "should" just work of running autoreconf with some
options |
21:37.21 |
brlcad |
there are no predefined steps that autoreconf
takes that you can replicate for all projects, it does different
things for different projects based on the contents of the build
system files like configure.ac/in, Makefile.am and other
files |
21:41.50 |
brlcad |
if there are no versioning mismatch problems,
bugs, or misconfiguration issues, all autogen.sh does is run
autoreconf for you |
21:45.08 |
Maloeran |
I'm sure it's the vim or Blender of
configuration scripts, I just wish it could be used properly
without learning so much |
21:45.49 |
Maloeran |
Although libtools has often behaved
erratically with me |
21:46.23 |
brlcad |
more like the 'ed' of editor interfaces
combined with the emacs feature list |
21:48.06 |
brlcad |
libtool is the weakest link and most bug
prone, but it also juggles the hardest part .. 90% of new-user
libtool problems that I've seen (even my own) have been incorrect
assumptions that happened to work somewhere but quickly broke under
different conditions |
21:49.10 |
brlcad |
contrary to autoconf and automake, libtool
usually doesn't abort during autoreconf when something is specified
wrong .. it just causes wierd/bad things to happen during
compile/linking |
21:49.29 |
Maloeran |
Example of erratical behavior. I made a copy
of the scripts generated by libtool to append a "gdb" in the "exec"
line, for obvious reasons |
21:49.53 |
brlcad |
yep |
21:51.30 |
Maloeran |
When the list of .o files change, these gdb
scripts become really weird. Sometimes, they work, and the next
moment, they don't ( nothing has changed ) with the script
complaining about some .o file |
21:51.30 |
Maloeran |
You may recompile without changing anything,
and it might work again, then stop doing so. It's just...
erratical |
21:51.30 |
brlcad |
why does the list of .o files
change? |
21:51.37 |
Maloeran |
Because a new .c file was added for
example |
21:52.01 |
brlcad |
if a new c file is added, and you update the
makefile.am, it's going to recompile the binary, and replace the
script |
21:52.23 |
Maloeran |
Right, but the old copy of the script with
"gdb" added isn't updated ; and the behavior of that script is
_really_ weird |
21:52.47 |
Maloeran |
I realize I should update the scripts every
time, but it really surprised me to see such inconsistant
behavior |
21:53.41 |
brlcad |
you've not said that was
wierd/inconsistent |
21:54.07 |
Maloeran |
What is weird is that the old copy of the
script with "gdb" added might sometimes work and sometimes does
not |
21:54.12 |
brlcad |
if you've added a new compilation object, the
presumably copied one that has a gdb added is invalid |
21:54.20 |
Maloeran |
And I'm talking about running it 2 times in a
row without changing anything else |
21:55.00 |
brlcad |
ahh, what you're seeing is due to the reason
the scripts exist in the first place too |
21:55.30 |
brlcad |
when you recompiled, the build deleted the
actual binary that your gdb script pointed to, which is actually
just a local lt-binary |
21:55.51 |
brlcad |
first pass through, it actually compiles/links
it when you run the script |
21:55.59 |
brlcad |
second pass, it has the lt- binary |
21:56.30 |
Maloeran |
So somehow it works the first time but not the
second?... It doesn't visibly compile anything |
21:56.35 |
brlcad |
still, that's very much a matter of
editing/running something that was/is invalid and shouldn't
work |
21:56.45 |
CIA-7 |
BRL-CAD: 03erikgreenwald * 10rtcmp/rtcmp.c:
compute and display speedup |
21:57.31 |
brlcad |
right, it doesn't blather about it, just
compiles behind the scenes, and it does this for a rather good
reason -- it's why it's a shell script there in the first place and
not just the binary |
21:57.58 |
brlcad |
if you want a binary that you can just run,
you can disable shared libraries during configure |
21:58.05 |
Maloeran |
I thought it was just to set the shared
library paths right |
21:58.17 |
brlcad |
that's one of the things it does |
21:58.30 |
brlcad |
how to do that portably depends on the
platform too |
21:58.55 |
brlcad |
so it relinks the binary so that it should run
without being installed (however that can be acheived for the
target platform) |
22:00.04 |
brlcad |
what ``Erik said is actually what you're
"supposed" to do according to the docs, the fact that adding a gdb
--args into the script works is about as significant as pulling out
a hex editor on a binary to get some modified behavior |
22:00.09 |
CIA-7 |
BRL-CAD: 03erikgreenwald * 10rtcmp/rt/rt.c:
compute and save the hit points and normals |
22:02.03 |
Maloeran |
All right, and this explains the "sometimes
works, sometimes doesn't" part |
22:03.24 |
``Erik |
it always works, it just doesn't do what you
expect :D |
22:03.24 |
CIA-7 |
BRL-CAD: 03erikgreenwald *
10rtcmp/adrt/adrt.c: extract the path string per region |
22:04.42 |
brlcad |
yep, almost guaranteed that it either notices
the lt-binary is missing or is at least out of sync timestamp-wise
(depends on your version of libtool), and it attempts to relink ..
which I would think would fail sometimes due to symbols missing and
othertimes for other reasons |
22:05.09 |
brlcad |
or at least what you want |
22:05.57 |
``Erik |
"do what I mean, not what I say!" |
22:38.06 |
IriX64 |
mea culpa, what time would you like me to
report to the firing squad? |
22:38.32 |
Maloeran |
At 26:14 and be on time! |
22:38.44 |
IriX64 |
Right captain. |
22:39.02 |
brlcad |
would you like fish sticks or peanut butter as
your last meal? |
22:39.13 |
IriX64 |
also explains why brlcad is channel op
:) |
22:39.39 |
IriX64 |
mmmmm sirloin, rare :) |
22:39.57 |
IriX64 |
trying to accuse me of buttering you
up? |
22:40.35 |
brlcad |
you're the wrong gender to be buttering me
up |
22:40.45 |
IriX64 |
it's configing happily now. thanks for the
tutorial. |
22:41.09 |
IriX64 |
thats for sure man... the parts were'nt meant
to go together :) |
22:41.13 |
brlcad |
seriously, though -- if you want to know how
the engine works, read through autogen.sh in detail -- at least the
comments |
22:41.21 |
IriX64 |
were'nt too. |
22:41.35 |
IriX64 |
already started. |
22:42.08 |
IriX64 |
I can safely be accused of being just a casual
*nix user. |
22:44.31 |
IriX64 |
and now it's happily "making" |
22:51.57 |
brlcad |
not really, other than perhaps having had this
discussion at least twice now about how you should read autogen.sh
if you really want to break things into pieces like that.. and I
think you've still not done that :P |
22:53.49 |
IriX64 |
45000000 Maloeran, thats a pricey
sentence. |
22:55.18 |
Maloeran |
Failure to paiment will return in spatial
confinement for 6.5*9^10 units of Plank time |
22:57.39 |
IriX64 |
Plank as in walk? |
22:57.44 |
IriX64 |
http://www.pastebin.ca/369597 |
22:57.57 |
IriX64 |
still working on this. |
22:58.27 |
brlcad |
i feel like a parrot with you sometimes
:) |
22:58.52 |
IriX64 |
heh you didn't have to go look :) |
22:59.02 |
brlcad |
that's some entirely unknown ld/cygwin/libtool
issue |
22:59.29 |
IriX64 |
agreed, funy thing is it keeps
compiling. |
22:59.34 |
brlcad |
your best bet is to install libz and/or libpng
on your own, add them as static libs to the build during
configure |
22:59.47 |
brlcad |
ah, now it's compiling? yesterday it was
failing? |
22:59.50 |
brlcad |
what'd you change? |
23:00.14 |
IriX64 |
build alias. |
23:00.23 |
brlcad |
huh? |
23:00.56 |
IriX64 |
--build=i686-pc-cygwin compiles,
--build=whatever compiles only with --disable switch. |
23:00.59 |
brlcad |
if people aren't supposed to click on a link
or derive something interesting by clicking on a link, then it
shouldn't be pasted :P |
23:01.33 |
IriX64 |
kindly telling me to watch what links i put in
the channel, noted and thank you :) |
23:03.17 |
brlcad |
I'd also think that there's no need to keep
thanking people after you're told things, I can't imagine that you
really are *that* thankful for everything .. |
23:03.30 |
brlcad |
maybe thank when it's thank-worthy, really
useful? :) |
23:03.35 |
brlcad |
just a thought :) |
23:03.40 |
IriX64 |
:) |
23:04.07 |
IriX64 |
I've never ever really grown up you see
:) |
23:04.19 |
IriX64 |
treat everybody like their my
parents. |
23:04.23 |
brlcad |
that much I gathered a really long time
ago |
23:04.44 |
brlcad |
I swore you were 12 for months |
23:04.56 |
brlcad |
still do some days |
23:06.42 |
IriX64 |
zasm was kinda fun too eh ``Erik? |
23:10.21 |
IriX64 |
do incompatible pointer types warnings
interest you? I can restart if they do. |
23:12.29 |
Maloeran |
Ignore, it's probably fine |
23:12.40 |
IriX64 |
ty |
23:13.17 |
IriX64 |
fixed Sc.c and cursor.c tho. |
23:13.50 |
IriX64 |
(char *) buncha times in both. |
23:21.41 |
brlcad |
IriX64: nah, it would be nice for someone to
actually go through and fix all of the warnings, especially make it
so that --enable-warnings comes up clean |
23:22.24 |
brlcad |
but that's mostly dusting under the lampshade
in the closet in the upstairs bedroom sorts of
maintenance |
23:44.20 |
IriX64 |
i might tackle it don't know about code will
never be executed though :) |
23:45.55 |
louipc |
salutations |
23:46.14 |
IriX64 |
and everybody hallucinated :) |
23:46.50 |
brlcad |
louipc: howdy loui |
23:48.06 |
Maloeran |
Some warnings can't be removed without
negatively impacting performance, annoyingly |
23:48.28 |
IriX64 |
tajke your pick clean or mean :) |
23:48.33 |
IriX64 |
take too. |
23:48.47 |
louipc |
I choose mean |
23:49.42 |
Maloeran |
I say efficiency above clean code, portability
and reliability! |
23:49.45 |
brlcad |
those are pretty darn rare, and usually imply
reliance on just compiler behavior that one probably can't be
guaranteed anyways (beyond compiler writer promises) |
23:50.33 |
Maloeran |
brlcad, such as these "variable might be used
unitialized" or even "variable is used unitialized" |
23:51.00 |
Maloeran |
Though the second one is very
specific |
23:51.02 |
louipc |
actually I choose portability |
23:51.06 |
brlcad |
the problem with efficiency, is that you can
blame so many things on that banner to the point of
rediculousness |
23:51.53 |
brlcad |
Maloeran: err.. using a variable that's been
uninitialized would be bad unreliable behavior |
23:52.19 |
``Erik |
bakebakebake |
23:52.25 |
brlcad |
that's usually something that might work on
one system/compiler, but could easily cause an outright crash on
another |
23:52.30 |
Maloeran |
It's not unitialized, but GCC isn't clever
enough to understand it. Pick a SSE m128 register, if you write
the lower and higher 64 bits independantely, GCC will complain it's
unitialized |
23:52.57 |
brlcad |
ahh, that's somewhat different -- that
borderlines on a false positive |
23:53.20 |
Maloeran |
Sure, I'm talking about these borderline cases
here, where removing the warning would reduce performance |
23:53.47 |
``Erik |
ohyeah, mal, it breaks on fbsd again, some _mm
ops that are named different or somethin' |
23:54.11 |
Maloeran |
That's weird, anything more
specific? |
23:54.15 |
brlcad |
that one in particular "probably" falls under
the "pretty darn rare" category, without seeing the actual
code |
23:54.40 |
``Erik |
I had it, but I forgot it, um, I suppose I
could regenerate the error :) |
23:55.13 |
``Erik |
updateupdateupdate |