| 02:00.42 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/librt/tree.c: stash the node into an argv for rt_gettree() so that it may be null-padded. helps debugging to see the boundary. |
| 03:14.06 | *** join/#brlcad paulMD-US (n=pbennett@pool-70-108-104-163.res.east.verizon.net) | |
| 03:15.09 | *** join/#brlcad paulMD-US (n=pbennett@pool-70-108-104-163.res.east.verizon.net) | |
| 03:16.03 | paulMD-US | Hey all... question for people.... is there an application within the brlcad package to generate traditional 2d CAD drawings from the 3d brlcad solid model? |
| 03:16.41 | *** join/#brlcad _AchiestDragon (n=dave@whipy.demon.co.uk) | |
| 03:23.24 | *** join/#brlcad DTRemenak (n=DTRemena@DHCP-170-143.caltech.edu) | |
| 03:42.13 | brlcad | paulMD-US: yes and no |
| 03:43.55 | brlcad | paulMD-US: for the edge-style drawings themselves, there is an application called rtedge that will render an edge-outline drawing |
| 03:43.57 | *** join/#brlcad _AchiestDragon (n=dave@whipy.demon.co.uk) | |
| 03:45.00 | paulMD-US | ohk... But there's no application for like dimensioning that drawing or anything like that? |
| 03:45.08 | brlcad | paulMD-US: what it doesn't do, and which we don't have a tool for yet is the means to draw annotations and dimensions onto that rendering (or the other raytracers for that matter) though this is being worked on as time permits |
| 03:45.39 | paulMD-US | OK .. thanx for the info! |
| 03:45.46 | brlcad | no problem |
| 03:45.54 | brlcad | feel free to help us implement it ;) |
| 03:46.23 | paulMD-US | yea... regretably I'm a better engineer than I am a programmer, hahaha |
| 03:46.29 | brlcad | :) |
| 03:47.06 | brlcad | there is likely going to be an annotation tool that will allow one to overlay annotations and dimensions onto a raytrace fairly soon (next few months) |
| 03:47.50 | brlcad | the longer-term work is going into adding full support for stashing annotations and overlays into the geometry file themselves as geometric objects akin to brl-cad's sketches |
| 03:48.28 | brlcad | everything's mostly in place for it already, it's just a limitation of time/resources and a few other higher-priority items |
| 03:56.02 | justin_ | mmm engineering |
| 04:14.34 | pra5ad | body implants w/ antennas |
| 04:14.43 | pra5ad | i smell a bad csi ep |
| 04:28.50 | justin_ | heh |
| 04:29.04 | justin_ | turns out sitting in my chair I get 1200kB/sec, away from computer I get 250kB/sec |
| 05:58.23 | *** join/#brlcad justin_ (n=justin@pcp0011649600pcs.aberdn01.md.comcast.net) | |
| 06:27.52 | *** join/#brlcad PKMOBILE (n=Apathy@pcp010175pcs.dover01.de.comcast.net) | |
| 07:31.14 | *** join/#brlcad clock_ (n=clock@84-72-88-230.dclient.hispeed.ch) | |
| 08:09.38 | brlcad | woot! |
| 08:34.50 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/librt/prep.c: quell a warning after repeat calls to rt_clean() since the rti_nsol_by_type wasn't getting set to zero when the memory was released. now it checks for the zero param to bu_free and clears the nsol value. |
| 08:41.09 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/gtools/g_transfer.c: (log message trimmed) |
| 08:41.10 | CIA-6 | BRL-CAD: now fully working, shooting rays at the remote geometry being held in-memory |
| 08:41.10 | CIA-6 | BRL-CAD: only. finishing polish fixes that were needed include making the dbi_title |
| 08:41.10 | CIA-6 | BRL-CAD: memory dynamic so librt doesn't try to free the static string, do the something |
| 08:41.10 | CIA-6 | BRL-CAD: during the ciao instead of after the server shuts down, and MOST IMPORTANTLY .. |
| 08:41.10 | CIA-6 | BRL-CAD: don't free the libpkg buf buffer that was used to set the external buffer, that |
| 08:41.12 | CIA-6 | BRL-CAD: gets stashed into the directory pointer, that must not be free'd when we try to |
| 08:44.27 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/NEWS: new g_transfer in-memory geometry example program |
| 09:57.00 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 10:02.43 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 10:46.05 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 11:36.25 | *** join/#brlcad pier (n=d9850efc@bz.bzflag.bz) | |
| 11:43.39 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 12:10.43 | *** join/#brlcad DTRemenak (n=DTRemena@DHCP-170-143.caltech.edu) | |
| 14:16.52 | *** join/#brlcad pier (n=pier@151.56.218.132) | |
| 14:22.06 | *** join/#brlcad cad383 (n=d9ba52c9@bz.bzflag.bz) | |
| 14:38.30 | *** part/#brlcad pier (n=pier@151.56.218.132) | |
| 14:41.48 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) | |
| 15:06.00 | *** join/#brlcad rednoon (n=chatzill@ags9-d9ba52c9.pool.mediaWays.net) | |
| 15:06.21 | rednoon | hello |
| 15:23.55 | *** join/#brlcad rednoon (n=chatzill@ags9-d9ba52c9.pool.mediaWays.net) | |
| 15:49.54 | *** join/#brlcad rednoon (n=michael@ags9-d9ba52c9.pool.mediaWays.net) | |
| 16:45.48 | *** join/#brlcad docelic (n=docelic@clj34-71.dial-up.arnes.si) | |
| 17:24.06 | *** join/#brlcad pier (n=pier@151.56.237.220) | |
| 17:56.35 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/gtools/.cvsignore: ignore g_transfer |
| 18:02.28 | *** join/#brlcad pier (n=pier@151.56.236.220) | |
| 18:16.25 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/librt/db5_io.c: protect from loosing memory and from otherwise potentially freeing what we are about to dup by stashing the pointer then freeing it. |
| 18:19.28 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/librt/ (db_flags.c db_alloc.c): move the db_flags_internal() to its own db_flags.c file as it has very little to do with allocations. also, add another routine for getting the flags from a db5_raw_internal as well. |
| 18:22.07 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/librt/ (db_inmem.c db_lookup.c): |
| 18:22.08 | CIA-6 | BRL-CAD: begin consolidating the in-memory-only database geometry support into one plcae. |
| 18:22.08 | CIA-6 | BRL-CAD: move db_inmem() to its own db_inmem.c file, adding two new routines for |
| 18:22.08 | CIA-6 | BRL-CAD: opening/creating in-memory databases via db_open_inmem() and db_create_inmem(). |
| 18:22.08 | CIA-6 | BRL-CAD: difference between the two being that create adds a _GLOBAL while open does not. |
| 18:22.39 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/librt/Makefile.am: add db_flags.c and db_inmem.c |
| 18:25.29 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/gtools/g_transfer.c: rename the dbip global to DBIP to distinguish it from local function dbip pointers. move the open/create/flag inmem routines into librt proper into the db_inmem.c and db_flags.c files. |
| 18:27.09 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/gtools/g_transfer.c: switch it back to db_open_inmem() instead of db_create_inmem() since testing is done, either should work fine but for this application, we don't need the _GLOBAL. |
| 18:28.16 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/include/raytrace.h: add declarations for the new routines in db_inmem.c and db_flags.c, namely db_open_inmem, db_create_inmem, and db_flags_raw_internal |
| 18:29.43 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/TODO: wrote the .g in-memory transfer example aplication |
| 18:35.59 | *** join/#brlcad pier_ (n=pier@151.56.192.151) | |
| 18:48.52 | *** join/#brlcad pier_ (n=pier@151.56.192.151) | |
| 19:00.37 | *** join/#brlcad cad761 (n=43621c7a@bz.bzflag.bz) | |
| 19:01.18 | *** join/#brlcad phcoder (n=phcoder@pcp0011650294pcs.aberdn01.md.comcast.net) | |
| 19:02.36 | *** join/#brlcad cad733 (n=43621c7a@bz.bzflag.bz) | |
| 19:16.05 | *** join/#brlcad cad010 (n=43621c7a@bz.bzflag.bz) | |
| 19:20.11 | *** join/#brlcad cad197 (n=43621c7a@bz.bzflag.bz) | |
| 20:09.53 | *** join/#brlcad IngMan (n=a8b0a00d@bz.bzflag.bz) | |
| 20:10.09 | IngMan | HI |
| 20:10.16 | IngMan | Hi Mos |
| 20:10.30 | IngMan | Hi Morrison |
| 20:16.30 | brlcad | hello IngMan |
| 20:17.56 | brlcad | if you refer to me as "brlcad", it'll usually get my attention faster |
| 20:20.24 | IngMan | k |
| 20:21.17 | *** join/#brlcad IngMan (n=a8b0a00f@bz.bzflag.bz) | |
| 20:22.32 | IngMan | hi BrlCAD |
| 20:23.30 | brlcad | heh |
| 20:24.17 | brlcad | brlcad for me brl-cad or BRL-CAD for the package ;) |
| 20:24.31 | IngMan | ok |
| 20:24.55 | IngMan | te acuerdas que te comente de manual en español |
| 20:25.04 | brlcad | si |
| 20:25.26 | brlcad | speaking of such.. pier has just finished up volume I in italian.. |
| 20:25.32 | brlcad | looking at it now |
| 20:28.13 | IngMan | i want talk about nirt command, but i dont know :( |
| 20:28.48 | brlcad | ah, yes |
| 20:29.49 | brlcad | there may likely be more information on nirt in the old printed documentation series from a long time ago |
| 20:30.11 | brlcad | i'll see if I can find anything in them |
| 20:30.23 | brlcad | (tomorrow, don't have them here with me now) |
| 20:30.35 | brlcad | otherwise, que quierias saber? |
| 20:31.18 | IngMan | cual es el objetivo del programa, no lo entiendo |
| 20:31.32 | brlcad | basicamente.. |
| 20:32.33 | brlcad | como se dice.. nirt tira rayos hacia objectos |
| 20:33.05 | brlcad | y te dice donde el rayo encuentra los objectos, que tan gruesos son |
| 20:33.56 | brlcad | quiza el material del objecto se tiene caracteristicas materiales |
| 20:34.12 | IngMan | ya |
| 20:34.25 | IngMan | eso era lo que yo pensaba |
| 20:34.39 | ``Erik | heh |
| 20:34.51 | brlcad | se puede usar por dentro de mged o separado |
| 20:35.40 | IngMan | listoç |
| 20:35.45 | brlcad | por ejemplo, abra un archive .g en mged, haga un 'e algo', y 'nirt' |
| 20:36.18 | IngMan | y de que otro comando seria bueno hablar |
| 20:37.31 | brlcad | nirt tambien se llama "query_ray" en mged |
| 20:38.01 | brlcad | bueno.. bastantes.. jmm |
| 20:38.05 | brlcad | rtedge |
| 20:38.07 | brlcad | rtwizard |
| 20:38.17 | brlcad | rt |
| 20:38.40 | brlcad | bastante mandatos de conversion |
| 20:39.09 | IngMan | si de esos ya los tengo casi todos aunque los mas importantes son iges y stl NO??? |
| 20:43.55 | IngMan | de casualidad tienes un .density ya creado |
| 20:46.23 | brlcad | depende en que te importa para decir quales son los mas importantes.. |
| 20:46.40 | brlcad | si, tengo un .density |
| 20:47.13 | IngMan | me permites copiarlo |
| 20:47.37 | brlcad | http://ftp.brlcad.org/tmp/.density |
| 20:49.00 | IngMan | thanks |
| 20:52.40 | IngMan | what program GPL is good for FEA |
| 20:53.19 | *** join/#brlcad cad485 (n=43621c7a@bz.bzflag.bz) | |
| 20:54.55 | *** join/#brlcad cad863 (n=43621c7a@bz.bzflag.bz) | |
| 20:56.05 | brlcad | IngMan: for the actual FEA, no se .. for meshing and preparation support, Cubit is very nice |
| 20:56.42 | brlcad | we're looking to collaborate with the Cubit folks sometime later this year |
| 20:56.47 | cad863 | A BRL-CAD question |
| 20:57.32 | phcoder | ls-dyna? you can download it, but I don't know if it's GPL |
| 20:57.48 | IngMan | only GPL or FREE |
| 20:57.52 | IngMan | ;) |
| 20:58.28 | IngMan | impact or Calculix |
| 20:59.17 | cad863 | My first time on IRC ... this is the preferred method of communicating with BRL-CAD devel. ... don't know proper manners for IRC. |
| 20:59.23 | IngMan | are good |
| 21:00.00 | cad863 | so how may I ask a question? |
| 21:01.54 | brlcad | cad863: just ask it |
| 21:01.56 | IngMan | simple, ask your question |
| 21:02.29 | brlcad | cad863: and yes, this is a preferred method, though the developer mailing list works too |
| 21:02.30 | cad863 | ah! there's someone. ok. |
| 21:03.01 | brlcad | ask the saying goes: |
| 21:03.02 | brlcad | ~ask |
| 21:03.04 | ibot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a quesiton first. Don't ask if a person is there, just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily. See also http://catb.org/~esr/faqs/smart-questions.html |
| 21:03.04 | cad863 | I've found bits and pieces alluding to a rollout of BRL-CAD on MS Win last November users meeting |
| 21:03.29 | brlcad | cad863: yes, finishing up that merge now actually |
| 21:03.30 | *** join/#brlcad AchiestDragon (n=dave@whipy.demon.co.uk) | |
| 21:03.46 | brlcad | been working on it almost non-stop |
| 21:03.49 | cad863 | when will it be available then? |
| 21:04.15 | brlcad | there's an alpha/beta-release available now if you're interested |
| 21:04.21 | brlcad | the first "real" release should be next month |
| 21:04.29 | brlcad | i.e. 2-3 weeks |
| 21:04.51 | cad863 | yes. primarily just need mged and VDECK ... with I suppose the associated RT |
| 21:05.11 | cad863 | I need to create ".cg" input files for a thermal model |
| 21:05.22 | brlcad | hm, not sure if it includes the vdeck converter, but it'd be easy to compile |
| 21:05.25 | cad863 | have done so on Solaris, but they want me to do Win |
| 21:06.09 | brlcad | rt and mged are definitely available |
| 21:07.02 | cad863 | I D/L'd the source, so just need do-it-myself instruction, a pointer to the right doc, or someone to just ship it to me :) |
| 21:07.32 | brlcad | like I said, I can give you a link to the nov. beta |
| 21:07.39 | cad863 | great! |
| 21:07.41 | brlcad | otherwise, it shouldn't be too hard to compile |
| 21:08.13 | brlcad | there are vc7 project files in misc/win32-msvc7 |
| 21:08.31 | brlcad | and last I checked, the entire package builds under mingw |
| 21:08.54 | cad863 | excellent. thanks much. |
| 21:11.40 | pier | wanted to go on with the short mged tutorial but can't find the link |
| 21:12.44 | brlcad | short mged tutorial? |
| 21:13.14 | pier | yes .. the one with the mug example |
| 21:13.27 | brlcad | ah |
| 21:13.31 | brlcad | the old one :) |
| 21:13.33 | pier | very short version of Vol. II |
| 21:13.39 | pier | yes |
| 21:13.44 | brlcad | that's in the doc/html directory |
| 21:13.50 | pier | it helped me a lot |
| 21:13.57 | pier | ok :) |
| 21:14.33 | brlcad | either in doc/html in a source checkout or in /usr/brlcad/share/brlcad/VERSION/html/ |
| 21:14.55 | pier | as soon as you think it is ok I'll get down with Vol.II |
| 21:17.53 | pier | or would it be better to go straight o it? |
| 21:18.48 | brlcad | pier: just read it .. looks great :) |
| 21:22.34 | pier | thanks... but unfortunately it wasn,t me the author of the content |
| 21:22.53 | brlcad | translating isn't easy or quick |
| 21:23.14 | pier | a mere translator... |
| 21:23.59 | pier | so do you think Vol II would be the proper task now? |
| 21:24.31 | pier | rather than the abridged old version |
| 21:24.49 | brlcad | yes and no |
| 21:25.07 | brlcad | you started with the html for the translation, translating the pdf that way isn't going to be nearly as easy |
| 21:25.40 | brlcad | and ultimately, it will need to be a structured format (for most all the docs) like docbook |
| 21:25.55 | brlcad | which hasn't even happened for english yet |
| 21:26.18 | pier | I see |
| 21:27.08 | brlcad | i mean, it'd take weeks to recode all of vol II regardless |
| 21:28.17 | brlcad | continue in the direction you were going -- the html doc tutorial |
| 21:28.31 | brlcad | that should be easier, and it'll give more time to think about what to do about volume II |
| 21:28.41 | pier | ok I'll see what can I make of it |
| 21:30.56 | pier | I'll show up as soon as I get somethig done |
| 21:31.08 | brlcad | sounds great |
| 21:32.20 | pier | ok see u then |
| 21:35.33 | *** part/#brlcad pier (n=pier@151.56.192.151) | |
| 22:17.37 | *** join/#brlcad mcaruso (n=mcaruso@pool-141-156-220-116.res.east.verizon.net) | |
| 22:18.58 | mcaruso | can anyone point me to an example that shows how to transform an object to a position and orientation? |
| 22:19.23 | mcaruso | within code |
| 22:20.57 | brlcad | mcaruso: src/proc-db examples do this (most of them) |
| 22:25.42 | brlcad | mcaruso: if you're using the libwdb routines for creating/positioning geometry, e.g. mk_addmember(), it returns a struct wmember* which contains the transformation matrix that will get written to disk |
| 22:26.15 | mcaruso | brlcad: Im not using anything right now, Im looking to see how to get started |
| 22:26.27 | mcaruso | brlcad: I am starting with an rt_i* |
| 22:26.54 | brlcad | mcaruso: it depends on your purpose -- if you're just writing out geometry, the libwdb interface is considerably simplified |
| 22:27.29 | mcaruso | brlcad: ok Im not writing out the geometry, its all in memory |
| 22:27.36 | brlcad | rt_i includes a pointer to a wdb pointer, it's more a matter of whether you'll want that saved to disk |
| 22:28.33 | mcaruso | brlcad: no need to save to disk |
| 22:28.38 | brlcad | er, rt_i includes a pointer to the wdb structure (rti_wdbp member) |
| 22:29.04 | brlcad | k, then you'll have to go through a little more work to convert the geometry into an in-memory version |
| 22:29.18 | mcaruso | hmmm |
| 22:29.28 | brlcad | not hard, i actually just finished writing a tool that does exactly that |
| 22:29.34 | brlcad | for a different purpose |
| 22:29.35 | mcaruso | ooooo |
| 22:29.57 | brlcad | the in-memory processing part that is, I don't modify the geometry though that becomes easy |
| 22:30.35 | brlcad | check out the src/gtools/g_transfer.c source in CVS head |
| 22:30.44 | mcaruso | ok |
| 22:31.17 | brlcad | i.e. http://cvs.sourceforge.net/viewcvs.py/brlcad/brlcad/src/gtools/g_transfer.c?rev=1.11&view=auto |
| 22:31.43 | brlcad | that program is a client and server example application |
| 22:31.53 | brlcad | (i.e. is run in one of the two modes) |
| 22:32.27 | brlcad | you run the server, connect to it with the client and the geometry is transferred to the remote host, kept in-memory only and processed from there (raytraced) |
| 22:33.35 | brlcad | two main routines are send_to_server() that the client uses to read the geometry off disk in a serialized format, to send to the server |
| 22:34.32 | pra5ad | g_transfer is what u created for mike? |
| 22:34.34 | brlcad | db_get_external(&ext, dp, dbip); gets the "external"/serialized format which is then sent to the server |
| 22:34.40 | brlcad | pra5ad: yes |
| 22:34.50 | brlcad | different mike :) |
| 22:35.05 | pra5ad | eh |
| 22:35.33 | brlcad | the server then gets the external/serialized geometry from the client and processes it with server_geom() |
| 22:36.50 | mcaruso | so if you were to make an animation lets say (movie) creating an in-memory version of the geoemtry is necessary, correct? |
| 22:37.22 | mcaruso | Im not making a movie but just using that as an example |
| 22:37.28 | brlcad | depends whether you're acticulating the geometry or the camera |
| 22:37.40 | brlcad | if it's just the camera, then no |
| 22:37.55 | mcaruso | yea lets say geometry |
| 22:37.56 | brlcad | that's just shooting rays from different locations/grids |
| 22:38.42 | mcaruso | and I guess it also means that if you need to move one object the entire scene also needs to be converted to in-memory |
| 22:39.06 | brlcad | not necessarily -- you can have pieces in memory, and pieces not in memory |
| 22:39.10 | mcaruso | ok |
| 22:39.36 | mcaruso | how can I verify that a model in a .g file is built around the origin? |
| 22:39.43 | brlcad | mged uses in-memory geometry while you are editing for example until you "accept" an operation |
| 22:39.51 | mcaruso | oh ok |
| 22:39.55 | brlcad | then it's written to disk replacing the non-in-memory version |
| 22:40.30 | mcaruso | cause im thinking I might not have to turn the geometry to in-memory |
| 22:40.45 | mcaruso | because I have an orientation and location of where I would like to place the object |
| 22:40.47 | brlcad | probably the easiest means to verify a model is built around the origin is to load the geometry, prep it, and look at the model bounding box |
| 22:40.54 | mcaruso | and I want to shoot a ray at it |
| 22:40.59 | mcaruso | ok |
| 22:41.30 | mcaruso | so I could create the matrix that would do a model->world transformation than get the inverse of that and multiply the position and direction vectors of my rays |
| 22:41.42 | brlcad | yeah, for isolated objects, you can fake matrix manipulations and trasnformations by just shooting from different locations |
| 22:42.08 | brlcad | it's when you need them in context among other objects simultaneaously that you need the in-mem version |
| 22:42.22 | brlcad | yeah, that should work |
| 22:42.25 | mcaruso | good point, cause I dont need that for the VL stuff |
| 22:42.31 | mcaruso | just one object |
| 22:42.32 | brlcad | right |
| 22:46.50 | brlcad | yeah, if it's only one object, then you wont need to deal with getting external/internal formats and creating the inmem -- a lot easier/simple to transform the rays |
| 22:49.47 | *** join/#brlcad DTRemenak (n=DTRemena@DHCP-170-143.caltech.edu) | |
| 23:30.31 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/other/awf/pass2.base: support ./" and .\" as an awf comment |
| 23:32.38 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/BUGS: our awf now supports ./" comments in addition to .\" ones |
| 23:37.45 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/NEWS: fixed brlman/awf `./"' unsupported or unknown issue |
| 23:51.15 | pra5ad | how can check if crond is running jobs correctly |
| 23:51.55 | ``Erik | it sends you email about what it's doing? o.O |
| 23:52.15 | *** join/#brlcad igotbsd (n=ricardo@adsl-10-15-31.mia.bellsouth.net) | |
| 23:52.23 | pra5ad | eh |
| 23:52.35 | pra5ad | by default? |
| 23:52.44 | ``Erik | yes |
| 23:52.56 | ``Erik | stdout and stderr get emailed to the user the cron job belongs to |
| 23:53.44 | pra5ad | hmm dont have an account setup |
| 23:54.52 | ``Erik | the cronjob has to belong to a user... |
| 23:58.14 | pra5ad | can i do this: explicitly append to /var/log/messages from the script in /etc/cron.hourly ? |
| 23:58.47 | ``Erik | uhmmmm, |
| 23:59.08 | ``Erik | if you can find or write something that sends to syslog, and pipe the output of cron.hourly crap to it? |
| 23:59.19 | ``Erik | I d'no if cron itself will talk to syslog directly |