| 00:09.24 | *** join/#brlcad ``Erik_ (n=erik@ftp.brlcad.org) | |
| 00:09.32 | ``Erik_ | points and laughs at starseeker some |
| 00:09.38 | ``Erik_ | points and laughs at starseeker some/part |
| 00:09.47 | *** part/#brlcad ``Erik_ (n=erik@ftp.brlcad.org) | |
| 00:09.58 | ``Erik | woops, accidently tapped the up arrow |
| 00:11.28 | ``Erik | it does seem to be dropping packets, though |
| 00:12.00 | ``Erik | or, rather, a router close to it is dropping packets :/ |
| 00:12.39 | brlcad | yeah, there's some networking problem |
| 00:12.46 | brlcad | 50-90% packet loss |
| 00:12.47 | ``Erik | with "pnap" |
| 00:12.56 | brlcad | been going since about 18:36 EDT |
| 00:13.26 | brlcad | seems to be a main sago router, main website doesn't come up nor various routers will ping without loss |
| 00:14.13 | ``Erik | traceroute indicates sago's uplink provider (pnap) is having issues between their backbone and sagos drop |
| 00:18.14 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) | |
| 00:26.14 | Ralith | brlcad: ping? |
| 00:32.13 | brlcad | Ralith: pong? |
| 00:37.13 | Ralith | there we are. |
| 00:37.47 | Ralith | was '16:02:36 < brlcad> yeah, same here' a reply to my comment on Qt? |
| 00:38.59 | brlcad | is painfully dealing with the network woes at the moment, apologies on delay |
| 00:39.10 | Ralith | no worries |
| 00:40.18 | brlcad | the "yeah, same here" comment was due to the networking problems.. went to the wrong channel |
| 00:40.23 | Ralith | ahh. |
| 00:40.46 | brlcad | I type and then it shows up anywhere from 1 to 60 seconds later |
| 00:41.02 | Ralith | that would be very frustrating. |
| 00:41.15 | Ralith | so, bad time to discuss UI toolkits further I guess :P |
| 00:43.36 | brlcad | is reading the backlog |
| 00:44.15 | brlcad | ah, I see now -- your comment |
| 00:44.35 | brlcad | I wouldn't pick qt for native integration capability, just a side comment I think |
| 00:44.55 | brlcad | it's more the other things (widget-wise) that qt or rbgui or whatever provide |
| 00:45.13 | brlcad | and no, I try not to sleep |
| 00:45.18 | brlcad | a piece of you dies every time you sleep! |
| 00:45.20 | Ralith | lol |
| 00:46.10 | Ralith | looks over Qt's widget offerings |
| 00:46.11 | brlcad | kanzure, you see the gsoc list of converters that folks could work on? :) |
| 00:46.22 | brlcad | I suspect that will answer your question about sldprt files |
| 00:46.43 | kanzure | heh |
| 00:46.50 | kanzure | that did turn up in my search results a few hours ago actually |
| 00:46.53 | kanzure | (the wiki page in particular) |
| 00:47.06 | brlcad | we show up on a lot of search results.. |
| 00:47.35 | brlcad | I often go hunting for something only to find a brl-cad page in the top list of results (or the top result) ... dammit! ;) |
| 00:47.39 | brlcad | if we had it, I wouldn't be loking :) |
| 00:48.03 | brlcad | we're just often apparently a main source for even discussing some matters |
| 00:48.16 | Ralith | BRL-CAD is extremely unique |
| 00:48.19 | Ralith | that has that result. |
| 00:49.12 | brlcad | actually I think it happened just yesterday when we were talking about guis and I went to search for that screenshot I was looking for |
| 00:49.35 | brlcad | top result was that wiki discussion page about gui options |
| 00:50.05 | brlcad | ah, the rbgui avi |
| 00:50.38 | brlcad | nay a link on rightbraingames, but our wiki sure came up |
| 00:50.56 | brlcad | dmaybeprobably just the way I phrased it |
| 00:51.19 | Ralith | helps that rightbraingames has barely a web presence |
| 00:51.29 | Ralith | and that you wrote most of the relevant wiki pages. |
| 00:52.18 | ``Erik | heh, I was looking for something about some archaic computer a few days ago and ended up at http://ftp.brl.mil O.o |
| 00:53.23 | Ralith | hmm, Qt's docs look really good. |
| 01:00.28 | *** join/#brlcad dreeves (n=dreeves@67.130.253.14) | |
| 01:11.42 | Ralith | in fact it looks pretty fun to dev for |
| 01:34.51 | ``Erik | the before, in the long long ago, I used qt due to the awesome docs and tutorials, but ended up switching to gtk+ because of the repaint on resize issue (as well as the painful compile times of c++ on a 120mhz cpu with 48m ram) |
| 01:34.51 | ``Erik | the before time, rather |
| 01:34.53 | Ralith | that's quite the before time. |
| 01:35.07 | Ralith | Qt still has painful compile times, but that shouldn't be a real issue |
| 01:35.22 | Ralith | since even devs will need to compile it at most once, barring upgrades |
| 01:41.01 | ``Erik | um, I meant compiling the programs that use qt :) |
| 01:41.09 | Ralith | ah. |
| 01:41.18 | Ralith | hopefully that isn't too bad. |
| 01:41.27 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 01:42.26 | ``Erik | hm, I'm under the impression that the BRL-CAD compile is disproportionately dominated by OpenNURBS (the only significant chunk of c++, iirc) :/ |
| 01:43.06 | Ralith | the BRL-CAD compile isn't that bad. |
| 01:43.25 | ``Erik | I know on this machine I'm running a portmanager on right now, c++ ports grind the machine down to a halt, and beat on swap a lot :( |
| 01:43.26 | Ralith | g3d should be a significantly smaller codebase, depiste C++ness |
| 01:43.40 | ``Erik | gtk+ compiles faster than cmake heh :( |
| 01:43.46 | Ralith | :P |
| 01:44.11 | ``Erik | pheer my 650mhz p3 with 128m ram! PHEER IT! |
| 01:44.36 | Ralith | lol |
| 02:04.00 | Ralith | brlcad: discovery! Qt appears to ship with support for drawing to OpenGL! |
| 02:04.01 | Ralith | :D |
| 02:07.32 | Ralith | brb |
| 02:28.15 | Ralith | returns |
| 02:42.27 | brlcad | ``Erik: openNURBS did increase the compile time by approximately 50-150% depending on plat, compiler, and memory |
| 02:43.28 | brlcad | and increased overall code size by about 20% with about 200k of sources |
| 02:43.47 | brlcad | c++ just compiles a whole lot slower than c |
| 02:44.48 | brlcad | Ralith: I know -- it wouldn't be very useful or interesting toolkit without an opengl widget :) |
| 02:44.54 | Ralith | nonono |
| 02:45.05 | Ralith | drawing to OpenGL a la stellarium |
| 02:45.13 | Ralith | that's not a custom hackjob there |
| 02:45.21 | Ralith | see: http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/ |
| 02:45.37 | Ralith | I grabbed and build the code; runs great, looks simple to duplicate |
| 02:46.27 | brlcad | ah, yeah, that too |
| 02:48.30 | brlcad | that's not quite what stellarium is doing iirc, but akin to Glitz |
| 02:49.24 | Ralith | what's stellarium doing, then? |
| 02:49.32 | Ralith | this seems to be what we need. |
| 02:50.41 | brlcad | iirc, they're inheriting off of the various qt widget classes and overriding the drawing routine |
| 02:51.09 | brlcad | instead just drawing an alpha-channeled image for many of those items |
| 02:52.16 | brlcad | the image drawing is still done through qt, though, so it has the option to use ogl acceleration to blit the image as texture quads on the backend |
| 02:52.26 | brlcad | *textured |
| 02:53.02 | Ralith | in the example I linked, if I'm reading it correctly, it's basically just saying "Here's my GUI; render it with OpenGL, please." |
| 02:53.12 | Ralith | and then overriding the background to draw the 3D stuff through normal OpenGL calls. |
| 02:54.20 | Ralith | of course, there'd be a bit more work in our case since there's the need to hook everything up to Ogre instead of pure OpenGL |
| 02:54.52 | brlcad | actually I think it'll work easier the other way around |
| 02:55.04 | Ralith | other way around? |
| 02:55.27 | brlcad | setting up the window/view/context(s) with qt and then initializing ogre at a lower level to use that context |
| 02:55.52 | Ralith | ah, you're probably right |
| 02:56.20 | brlcad | instead of starting up with ogre and finding a way to initialize qt to use it |
| 02:56.42 | Ralith | I think there's even some example code of putting Ogre inside Qt that could be leveraged |
| 02:56.52 | Ralith | since it's basically the same mechanisms |
| 02:56.57 | brlcad | yep |
| 02:58.37 | Ralith | sounds like a plan. |
| 03:03.09 | brlcad | "The network issue has been resolved. There was a major DDoS attack that flooded Sago's bandwidth. The IPs that were being attacked have been null routed which stopped the DDoS attack." |
| 03:03.23 | Ralith | yay! |
| 03:31.25 | Ralith | brlcad: where does submitting a formal gsoc application fit in to the participation checklist? |
| 03:32.23 | Ralith | it's suggested elsewhere that commit access should be obtained beforehand, but that's the last item on said list, which also includes references to mentor discussions and design docs and such, which seems inconsistent. |
| 03:35.54 | Ralith | to put it more simply, I'm wondering what I should get done before sending in my app; for example, should I update the OpenGL GUI page with documentation of what we've discussed? |
| 03:35.55 | brlcad | Ralith: the participation checklist is for those already applied and selected, sort of a to-do list after the fact |
| 03:36.00 | Ralith | ahh. |
| 03:36.24 | brlcad | the getting started section at http://brlcad.org/wiki/Google_Summer_of_Code is the first steps |
| 03:36.39 | Ralith | because it contains many items that are elsewhere emphasized as things to do beforehand. |
| 03:36.46 | brlcad | yeah, it overlaps |
| 03:39.22 | brlcad | independent lists each with items not on the other .. should probably combine them into one, one list with two sections perhaps |
| 03:40.19 | brlcad | e.g., first one says to interact on #brlcad , the other is specific to introduce yourself (and your project) |
| 03:40.23 | brlcad | if you hadn't already |
| 03:40.46 | Ralith | kk |
| 04:12.02 | *** join/#brlcad copenhague (n=copenhag@d206-75-233-96.abhsia.telus.net) | |
| 04:21.53 | Ralith | brlcad: is scripting language support a responsibility of the editor, or something to be provided by an external library? |
| 05:44.50 | starseeker | Arrrgh - I wish I wasn't broke... http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ssPageName=STRK:MEWAX:IT&item=250395300975 |
| 05:46.39 | starseeker | oh well, no storage anyway |
| 05:49.23 | Ralith | now that would be cool to model. |
| 05:49.54 | Ralith | we should build up a bunch of neat blueprints like that and suggest people model them for future SoCs :D |
| 06:37.35 | *** join/#brlcad madant (n=madant@117.196.144.31) | |
| 06:49.25 | *** join/#brlcad madant (n=d@117.196.144.31) | |
| 07:24.33 | yukonbob | hello, cadheads (from Las Vegas!) |
| 07:25.45 | Ralith | hello, yukonbobhead! |
| 07:25.50 | Ralith | what're you up to down there? |
| 07:28.45 | yukonbob | Ralith: hi |
| 07:29.49 | yukonbob | Ralith: visiting wife + kid... I'm working in Vancouver, she's working in Alberta (with baby), and believe it or not, this was convenient. |
| 07:30.18 | yukonbob | (she' was presenting paper earlier this week in Vegas; she's a cultural anthropologist) |
| 07:30.25 | Ralith | that doesn't sound like much fun :/ |
| 07:30.34 | Ralith | (the vancouver/alberta thing, not the paper thing) |
| 07:30.36 | yukonbob | Ralith: no fun at all... |
| 07:30.48 | yukonbob | Ralith: looking forward to the end of this situation |
| 08:44.25 | Ralith | brlcad: you there? |
| 08:44.29 | brlcad | yep |
| 08:44.59 | Ralith | how does 'stubbing' functionality by backing it with libged sound? |
| 08:45.23 | Ralith | will the interfaces be similar enough for it to be easily converted to the geometry service? |
| 08:45.50 | brlcad | scripting support is going to be handled by the front-end, but probably a plugin facility in the geometry service's domain |
| 08:46.11 | brlcad | or a layer in-between |
| 08:46.49 | brlcad | that sounds good -- that's sort of what mafm's work to date did |
| 08:47.09 | Ralith | I wasn't aware that mafm's work to date did much talking to BRL-CAD at all. |
| 08:47.59 | Ralith | re: scripting, that leaves me a little unclear |
| 08:48.25 | Ralith | g3d is expected to implement scripting in the short term, but eventually it will be separated out? |
| 08:49.32 | brlcad | yeah, it already uses libged to open a .g geometry file, display geometry, undisplay, etc |
| 08:50.49 | Ralith | ah. |
| 08:50.51 | brlcad | basically, most things will have to be handled by the application in the short term and/or worked with the other bigger projects as they come to fruition |
| 08:51.08 | Ralith | kk |
| 08:51.29 | Ralith | sounds like a standalone scripting system would make yet another good soc project |
| 08:51.34 | Ralith | well |
| 08:51.36 | Ralith | maybe not |
| 08:51.43 | Ralith | as it'd have a pretty ill defined interface for the time being, I think |
| 08:52.15 | brlcad | example, when this is done, an application wouldn't need (or want) to have to maintain ged structures -- that would happen by the service automatically |
| 08:53.08 | brlcad | the goal is for the client to be a thin-client, minimum functionality with most of the logic happening on an application-backend through a plugin-architecture |
| 08:53.32 | brlcad | notes that this is better explained with pictures, but maybe you get the gist |
| 08:54.10 | Ralith | I think I do, especially since it's a very clean way to do things. |
| 08:54.12 | Ralith | very unixy. |
| 08:54.32 | Ralith | which is something increasingly (and worryingly) rare among large-scale projects. |
| 08:54.50 | brlcad | that's why, though, I was mentioning yesterday that the goal shouldn't be so much to focus on how it interacts with geometry, libged, librt, geometry engine, geometry service, et al, but to work on the gui itself and getting that framework set up (polished, clean look and feel, etc) |
| 08:55.00 | Ralith | yeah |
| 08:55.02 | Ralith | that makes perfect sense |
| 08:55.16 | Ralith | no point spending devtime on something that'll be deprecated in short order, and was never really good practice to start with. |
| 08:55.51 | brlcad | a little less exciting perhaps, but it's the only known step without -- as you note -- working on a backend feature like a scripting module in the geometry service |
| 08:55.59 | brlcad | which would be cool, but yeah -- another project in itself |
| 08:56.38 | brlcad | right, the measures g3d already goes to for opening a .g is arguably already "too much", but it is nice to at least be able to see some geometry :) |
| 08:56.50 | Ralith | I dunno, there's a *lot* of awesome-factor in building a script-independent scripting system as you've described. |
| 08:56.52 | brlcad | and libged does make that really easy |
| 08:57.50 | Ralith | I figure having enough of a backend to enable meaningful tests of usability is important. |
| 08:58.06 | Ralith | it's hard to study how practical something is to complete a task if you can't actually complete the task. |
| 08:59.07 | Ralith | by the way, is the BREP stuff still not very far along? I'm wondering how far we are from easy tesselation of arbitrary geometry. |
| 08:59.22 | Ralith | 'cuz that could ad major shiny-points to a demo. |
| 08:59.32 | brlcad | there has been some progress, but nothing you could rely on for gsoc |
| 09:00.17 | brlcad | still, even if it could do wireframe, or shaded display of unevaluated CSG, that much is all doable now |
| 09:00.41 | Ralith | good point |
| 09:00.58 | Ralith | unevaluated is plenty for some nice looking demos. |
| 09:01.26 | brlcad | and for mesh models, they'll look the same |
| 09:01.36 | brlcad | no booleans |
| 09:01.50 | Ralith | well, mesh models isn't really what we're here for |
| 09:02.07 | Ralith | though that would work well for pretty pictures. |
| 09:03.13 | brlcad | yep |
| 09:07.11 | brlcad | as for the scripting separation, if you think of the application having a front-end and a back-end, where the front is the gui (or the V in an MVC separation) and the back contains modular functionality in plugins |
| 09:07.51 | brlcad | one of the back modules is a command shell, that effectively provides a terminal service |
| 09:08.48 | brlcad | within that terminal service, you're basically running a command shell (e.g., tclsh, bash, python that (for now) hooks through those environments to libged) |
| 09:09.07 | *** join/#brlcad madant (n=d@117.196.141.132) | |
| 09:10.09 | brlcad | that command layer itself would be a nice contained project in itself because it's easy enough to whip up an application testing harness that provides a command prompt and lets you switch between different scripting languages on the fly |
| 09:10.37 | Ralith | hm |
| 09:10.52 | Ralith | so [GUI actions trigger] commands trigger editing actions? |
| 09:11.11 | brlcad | explain? |
| 09:12.00 | Ralith | I'm having trouble seeing how the command line could be a plugin without duplication of the editing bindings between the GUI and the scripting system. |
| 09:12.15 | Ralith | unless the GUI is a wrapper of the command line |
| 09:12.48 | Ralith | which could work, assuming multiple shells can be used, and has some neat side effects like being able to easily show a command for every gui action. |
| 09:13.25 | brlcad | the latter -- every action in the system can be defined as a series of scriptable non-modal command actions |
| 09:13.44 | brlcad | that's actually how the geometry service is presently organized |
| 09:13.59 | Ralith | okay |
| 09:14.10 | Ralith | so multiple shells can be used in parallel then? |
| 09:14.14 | Ralith | could be confusing. |
| 09:14.15 | brlcad | absolutely |
| 09:14.33 | brlcad | that'd be up to the app to limit is possible |
| 09:14.52 | Ralith | oo, I know |
| 09:14.54 | brlcad | present an actual terminal window, for example |
| 09:14.56 | Ralith | command prompt. |
| 09:15.02 | Ralith | shell-specific prompt. |
| 09:15.06 | brlcad | right |
| 09:15.08 | Ralith | that would disambiguate nicely |
| 09:15.17 | Ralith | also minimize confusion when using someone else's workstation |
| 09:15.32 | *** join/#brlcad madant_ (n=d@117.196.141.132) | |
| 09:15.33 | brlcad | that's what I was saying about running a command shell (within a terminal service) |
| 09:15.51 | Ralith | hm? |
| 09:15.56 | brlcad | terminal is basically a given console, in that console, you'd only be running one shell at a time |
| 09:16.10 | brlcad | but could certainly switch shells if you wanted |
| 09:16.23 | brlcad | just like a unix command terminal/console |
| 09:16.42 | Ralith | I was imagining the situation in which the g3d user is running an arbitrary shell |
| 09:16.49 | Ralith | the GUI would have to use its own console |
| 09:17.11 | Ralith | which prevents awesome stuff like sharing command history between GUI actions and manually entered commands |
| 09:17.17 | brlcad | wouldn't exactly be arbitrary as we'd have to make it work for each shell we want to support |
| 09:17.31 | Ralith | arbitrary in the sense that it might not be the one the GUI's using. |
| 09:17.39 | brlcad | they would have a shared command history, though |
| 09:17.46 | Ralith | how do you do that across different shells? |
| 09:17.52 | brlcad | that's where everything is eventually going to filter through the geometry service |
| 09:17.56 | Ralith | different syntaxes. |
| 09:18.08 | Ralith | you'd have to have some sort of action -> shell command convertor |
| 09:18.14 | brlcad | that's actually where commands will be handled -- just right now, that's in libged |
| 09:18.56 | Ralith | and you'd need to go from GUI shell -> abstract action -> user shell just to generate the history entry. |
| 09:19.04 | Ralith | or am I misunderstanding? |
| 09:19.43 | brlcad | more like "gui action -> gs command(s) -> ged command(s)" and "terminal command -> gs command -> ged command" |
| 09:20.15 | Ralith | ah. |
| 09:20.23 | Ralith | I was referring to command history in the shell context. |
| 09:20.41 | Ralith | this would be a valuable learning tool, because it'd show you how to do everything you depend on the GUI for by hand. |
| 09:21.16 | Ralith | not critical to a functional interface, sure, but I bet it would drastically increase the use of the more advanced capabilities granted by scripting. |
| 09:21.30 | brlcad | ah yeah .. making the terminal show history for gui actions would just be confusing I think -- I see that happening as more of a command transcript |
| 09:22.03 | brlcad | where you could ask the gs for a history transcript, and you'll see combined gui and/or console commands |
| 09:22.20 | Ralith | yeah, I follow |
| 09:22.44 | Ralith | I just really like the idea of showing users how to do things a more efficient way. |
| 09:23.09 | brlcad | most of the gui actions are asynchronous, most of the console are synchronous (at least by default) |
| 09:23.11 | Ralith | there won't be nearly as much use of the command line if you have to dig into documentation to use it. |
| 09:24.02 | Ralith | but I suppose my point this whole time is that a good design makes that impractical. |
| 09:24.28 | brlcad | makes what impractical? |
| 09:25.24 | Ralith | mapping GUI actions onto shell commands |
| 09:25.47 | brlcad | ah, yeah |
| 09:26.06 | brlcad | I mean you could -- gs commands will map pretty much 1-1 with shell commands |
| 09:26.32 | Ralith | but would it be practical to go from gs command to shell command? |
| 09:26.33 | brlcad | that's why you'll be able to pull up an editing history regardless of actions being performed through the gui or via command-line |
| 09:26.43 | Ralith | and beyond that, there's higher level stuff that could be mapped but would do so really badly |
| 09:26.49 | Ralith | e.g. complex chains of actions |
| 09:27.10 | Ralith | things that would take significant amounts of script to produce |
| 09:27.14 | brlcad | yeah -- many gui actions will translate to multiple commands, even a single "click" |
| 09:27.58 | brlcad | which could later be abstracted out into a single meta-command possibly, but there will always be something even more "meta" possible |
| 09:28.04 | Ralith | yup. |
| 09:28.15 | Ralith | which, I suppose, dooms the whole idea, irrespective of implementation details. |
| 09:29.51 | brlcad | if you recall the command prompt in the IOE demo, that's basically a single command that would feed/translate directly to the gs as a gs command and map 1-1 with a ged command |
| 09:30.10 | brlcad | and be an "action" that is scripting agnostic, raw command |
| 09:30.14 | Ralith | yeah |
| 09:30.33 | Ralith | but a proper implementation should allow full expressions, be they oneliners, in that context imo |
| 09:30.45 | Ralith | which includes things like loops which map onto many gs commands. |
| 09:31.08 | brlcad | not for the on-demand command prompt -- there is no interpreter |
| 09:31.16 | Ralith | oh? |
| 09:31.29 | Ralith | are you sure that's a good idea? |
| 09:31.56 | Ralith | you'd need to define a human-readable (and succinct enough to be enterable) syntax for gs commands |
| 09:32.03 | Ralith | and it'd detract from the power significantly. |
| 09:32.19 | brlcad | there is *still* a command console |
| 09:32.31 | brlcad | i'm referring to the on-demand command prompt |
| 09:32.38 | brlcad | which is separate from the console prompt |
| 09:32.53 | Ralith | I had thought that would just be a convenient method of accessing it. |
| 09:34.00 | brlcad | it's possible that the on-demand prompt could allow some form of one-liner scripting, but would not want to complicate it's simple expressivity for things that the command console will handle already |
| 09:35.07 | Ralith | the command console can handle simple 1:1 commands too, though |
| 09:35.19 | Ralith | so I don't see how such a shell is out of place in the on-demand prompt. |
| 09:35.29 | Ralith | or, wait |
| 09:35.33 | brlcad | yes it's 1-1, but it does it within a shell |
| 09:35.38 | Ralith | the prompt is focused on UI actions? |
| 09:35.41 | *** join/#brlcad madant (n=d@117.196.141.132) | |
| 09:35.44 | brlcad | and you can switch shells |
| 09:35.50 | Ralith | rather than the shell being focused on editing actions? |
| 09:36.09 | brlcad | not sure I understand your question |
| 09:36.36 | Ralith | e.g. you'd use the prompt to save a file to local disk, and the shell to create a region. |
| 09:37.29 | Ralith | in the IOE demo the shell was for performing environment and overarching UI related actions, rather than directly controlling the programs. |
| 09:37.40 | Ralith | er |
| 09:37.43 | Ralith | the on demand prompt |
| 09:40.34 | brlcad | there was no shell in the IEO demo, just that on-demand command prompt -- but yeah, that on-demand could potentially allow environment/ui actions or lower-level commands |
| 09:40.59 | brlcad | those can happen on a terminal console as well, though, as it's all going through the same system |
| 09:41.24 | brlcad | I don't see much of the gui being inaccessible from the command prompt |
| 09:42.18 | Ralith | then I'm kind of confused as to why we need to introduce an entirely new syntax to what could just be another interface to the shell. |
| 09:42.32 | brlcad | be able to be in either and affect the other, or at least introspect the other as the "model" is still being managed by the backend gs state and both the command prompt and gui just reflect that state |
| 09:42.52 | brlcad | what OS do you use? |
| 09:42.59 | Ralith | *nixes in general |
| 09:43.02 | Ralith | Linux at the moment |
| 09:43.15 | Ralith | though I do find myself at windows often. |
| 09:44.40 | brlcad | that on-demand prompt is inspired by and modeled after application launchers |
| 09:45.08 | brlcad | akin to "quicksilver" on a mac if you've ever used that |
| 09:45.10 | Ralith | my ideal application launcher is a quick-loading one-line terminal. |
| 09:45.14 | Ralith | I haven't. |
| 09:45.49 | brlcad | I believe "Launchy" is sort of similar (just not nearly as awesome as quicksilver) for linux and windows |
| 09:45.58 | Ralith | haven't used that either >_> |
| 09:45.58 | brlcad | http://en.wikipedia.org/wiki/Quicksilver_(software) |
| 09:46.02 | Ralith | I keep my UI simple. |
| 09:46.12 | brlcad | ahh, here http://en.wikipedia.org/wiki/Comparison_of_application_launchers |
| 09:46.13 | Ralith | running xmonad, a minimalist tiling window manager, at the moment. |
| 09:46.18 | brlcad | nods |
| 09:46.36 | Ralith | window management in the IOE reminded me of it. |
| 09:47.35 | brlcad | basically it's a way to "DO THIS" on-demand when you don't have an interactive command prompt available, accessed via a quick hot-key like alt+space |
| 09:47.43 | Ralith | I follow |
| 09:47.54 | Ralith | but I don't see how that's not offered by a shell. |
| 09:48.04 | brlcad | it is offered by the shell |
| 09:48.20 | brlcad | but the shell is something persistent or something you launch, stays around, uses screen real-estate, etc |
| 09:48.24 | Ralith | then why go to the effort of specifying an entirely new syntax? |
| 09:48.34 | Ralith | shell in the sense of the actual interpreter |
| 09:48.45 | Ralith | not the terminal that's displayed |
| 09:49.12 | Ralith | it seems like this would add a significant amount to what you'd have to learn for relatively little benefit. |
| 09:49.31 | Ralith | which infringes on the critical usability factor. |
| 09:49.48 | Ralith | since it is, in effect, an entirely new 'language' |
| 09:49.54 | brlcad | could just be a terminology mismatch, shell to me means 'command shell' in a traditional sense like bash/tcsh/tclsh, those are shells -- entire interpreter environments |
| 09:50.13 | Ralith | that's what I mean |
| 09:50.27 | Ralith | the entry box wouldn't be persistent, but the interpreter can be. |
| 09:50.37 | brlcad | there is no new language, it basically is the common subset of all shell interpreters |
| 09:50.40 | Ralith | which is nice, because it allows for continuous state |
| 09:50.50 | Ralith | how do you do that when they have such varied syntax? |
| 09:50.52 | brlcad | the interpreters without their scripting harness -- the command portion |
| 09:51.28 | Ralith | you'd have to limit supported interpreters to those with identical function call syntax, or something. |
| 09:51.38 | Ralith | I can't see that working at all; I must be missing something |
| 09:52.12 | brlcad | not sure what syntax you're referring to that would be different.. there is no syntax to learn other than the commands themselves, which are mostly verb+noun or noun+verb |
| 09:52.36 | Ralith | not so in python, afaik |
| 09:52.39 | Ralith | that's much more C like. |
| 09:53.04 | Ralith | it's largely a coincidence that the popular shells that consist of most of your examples tend to offer similar command syntax. |
| 09:53.29 | Ralith | and even for them things like setting variables differ, although that may be outside of the scope you describe. |
| 09:53.38 | brlcad | it's really hard to explain given you've not used any of those application launchers :) |
| 09:53.47 | Ralith | these application launchers all use their own language. |
| 09:53.51 | Ralith | it's a very simple one, yes |
| 09:53.56 | Ralith | but it's still something you have to learn |
| 09:53.56 | brlcad | yes, there is no state, no variables, no scripting. just a "do this" |
| 09:54.05 | Ralith | so it's another language. |
| 09:54.18 | brlcad | not really |
| 09:54.32 | Ralith | and thus another barrier to optimal usability--although I suppose that's limited, since the actions would be replicated in the other two environments.. |
| 09:55.06 | Ralith | well, I imagine shell syntax for something is usually going to be very different from prompt syntax for it. |
| 09:55.17 | Ralith | just as the GUI way of doing something would be. |
| 09:56.01 | Ralith | it may be a very simple language, and even a very intuitive one, but it's still something clearly differentiated from a shell. |
| 09:56.34 | brlcad | back to the original example where a single gui action would translate to one or more 'gs commands', the on-demand prompt is basically a 1-1 to a gs command as well |
| 09:56.35 | Ralith | but I'm realising now that that's not such a disadvantage, given that its use is entirely optional. |
| 09:57.04 | Ralith | and that new users won't be depending on a GUI element they've never encountered before. |
| 09:57.38 | Ralith | you've still got to define the language, simple as it may be. |
| 09:57.52 | brlcad | I still don't get where you're getting language from |
| 09:58.01 | brlcad | there is no logic/syntax other than "command + args" |
| 09:58.10 | brlcad | there are no variables, no conditionals |
| 09:58.17 | brlcad | to logical constructs |
| 09:58.20 | brlcad | s/to/no/ |
| 09:58.26 | Ralith | okay. |
| 09:58.35 | Ralith | you've still got to define a set of these commands. |
| 09:58.40 | brlcad | "draw object" |
| 09:58.49 | Ralith | I guess that wouldn't be that much more work than binding a new scripting language at that point, though |
| 09:58.51 | brlcad | absolutely, that we're doing implicitly with libged |
| 09:58.57 | Ralith | huh? |
| 09:59.12 | brlcad | that defines a set of understood geometry editing commands in a "command+args" structure |
| 09:59.21 | Ralith | ah. |
| 09:59.34 | Ralith | and it'd be a simple matter to map literal commands onto that. |
| 09:59.49 | brlcad | example literal command? |
| 09:59.58 | Ralith | draw object |
| 10:00.07 | Ralith | (as opposed to the actual ged library call) |
| 10:01.04 | brlcad | that might be the missing link -- ged library calls are intentionally a collection of commands as functions |
| 10:01.20 | Ralith | which is why it's a simple matter. |
| 10:01.24 | brlcad | pretty every mged command now corresponds to a libged function |
| 10:01.28 | brlcad | a single function |
| 10:01.37 | brlcad | ged_[command]() |
| 10:02.32 | brlcad | so you say "draw object", that basically calls ged_draw(argc=2, argv={"draw", "object"}); |
| 10:02.41 | brlcad | plus a ged state structure |
| 10:03.07 | brlcad | so it knows in what context to invoke that command |
| 10:04.03 | brlcad | so we are defining commands, sets of commands, and arguments, but the intent is that those remain modular modeless actions |
| 10:04.29 | brlcad | a gui action may translate to 100 ged_*() commands through the geometry service |
| 10:05.20 | brlcad | the command terminal will allow scripting in an environment, provide variables and logical structures, and basically map commands directly to their ged_* counterparts |
| 10:05.38 | Ralith | or as closely as permitted by the shell. |
| 10:05.40 | brlcad | an on-demand command basically maps directly to one ged_* command |
| 10:06.01 | brlcad | example? |
| 10:07.04 | brlcad | all command shells I know of boil down (or can be boiled down) fundamentally to command+args |
| 10:08.11 | Ralith | well, python isn't a command shell in the traditional sense, for example |
| 10:09.14 | brlcad | especially all interactive prompts like bash/tclsh but even non-interactives like python/lisp/perl translate |
| 10:10.18 | Ralith | I mean, the syntax will differ between calling a python function and executing a bash command. |
| 10:11.16 | brlcad | oh yeah, syntax will definitely differ -- that "translation" is what I was referring to earlier about having to take efforts to hook in a new scripting interface |
| 10:13.24 | brlcad | for an object-based language like python, a really simple way to avoid most of the issues is to make a "ged object" that then becomes your object that takes "command+args" parameters |
| 10:14.00 | brlcad | at least one of several ways it could be handled |
| 10:14.56 | brlcad | there the difference is mostly noun+verb's instead of usual verb+noun's style you find elsewhere |
| 10:15.25 | brlcad | that's where something like swig should hopefully make life a little easier since we just define the functions/commands and then swig does the mappings to various languages for us |
| 10:15.39 | Ralith | yeah. |
| 10:18.37 | brlcad | i guess the original point about the on-demand command prompt, though, was simply that it would effectively be like the mged command prompt without the tcl scripting capability -- syntax is identical and basically becomes a way to run a single command very quickly (and transiently) |
| 10:19.16 | brlcad | not strictly necessary, more of a power-user function at that, but much less intrusive than a terminal (and generally *much* faster/efficient too) |
| 10:23.26 | Ralith | yeah, I follow |
| 10:23.26 | Ralith | makes sense now. |
| 10:23.50 | Ralith | It might be worth considering offering a similar functionality that pipes into the shell, too, though |
| 10:24.06 | Ralith | simply because it'd be handy to be able to access the shell interface from anywhere with a minimum of effort. |
| 10:24.19 | Ralith | or so I imagine |
| 10:24.23 | brlcad | I'd hope a hot-key that pops up the terminal? |
| 10:24.46 | brlcad | I'd like an on-demand *terminal* as well, one that you can hide/unhide, but that is always available |
| 10:25.10 | brlcad | ideally overlayed on the display |
| 10:25.17 | brlcad | like command overlays for most games |
| 10:27.08 | Ralith | that provides that pretty well, then. |
| 10:33.30 | Ralith | brlcad: submitting my first draft proposal now. |
| 10:33.35 | brlcad | cool |
| 10:34.36 | Ralith | I went on for a while about it, and made an effort to provide the relevant background, so I hope it isn't overly verbose. |
| 10:35.17 | Ralith | quite open to suggestions for changes. |
| 10:40.08 | Ralith | in fact, please do let me know if you have any input. |
| 10:41.13 | Ralith | tomorrow I'll see if I can write another one up for the de-TCLification of the std libs, but I think it's late enough tonight,. |
| 10:53.18 | brlcad | alright cool |
| 10:55.40 | Ralith | thanks for the discussion |
| 11:01.50 | brlcad | likewise |
| 11:02.32 | brlcad | good to get some of this stuff out of my head, and to bounce old/new ideas off of others |
| 11:03.10 | brlcad | I really need to upload all of the design and docs that have gone into things to date (along with a ton of other BRL-CAD things that would be cool to upload) |
| 11:07.01 | Ralith | like what? |
| 11:09.17 | brlcad | hard to categorize, it's a lot of stuff |
| 11:10.26 | brlcad | renderings/images, technical papers, design documents, tutorials, various data sets, geometry models, .. |
| 11:10.37 | Ralith | sounds neat |
| 11:10.52 | Ralith | any reason not to just throw it up somewhere and work it out from there? |
| 11:14.12 | *** join/#brlcad madant (n=d@117.196.129.159) | |
| 11:18.12 | brlcad | yeah, some of it would be very misleading, some of it is not republishable as-is, some of it is almost entirely useless, it needs at least a pass through |
| 11:18.59 | brlcad | like in my gui research, there are dozens of shots and mockups of an LCARS interface (from star trek) |
| 11:19.24 | brlcad | was just for kicks many years ago while thinking through some ideas and wouldn't really be useful for anything |
| 11:19.39 | Ralith | ah, misleading would be a problem. |
| 11:19.43 | brlcad | more distraction and FUD factors of having too much junk |
| 11:19.55 | Ralith | makes sense |
| 11:26.04 | *** join/#brlcad ashishrai (i=d2d43dfb@gateway/web/ajax/mibbit.com/x-ccc367e0f5cc43d6) | |
| 13:11.11 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 13:12.44 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) | |
| 14:38.00 | *** join/#brlcad madant (n=d@117.196.139.99) | |
| 16:11.41 | *** join/#brlcad ashishrai (i=dce36163@gateway/web/ajax/mibbit.com/x-977581b739ac3c13) | |
| 16:13.40 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 17:58.37 | brlcad | starseeker: coil command needs a manual page to be in src/shapes |
| 18:00.42 | CIA-40 | BRL-CAD: 03brlcad * r34101 10/brlcad/trunk/NEWS: annotate the 7.14.4 release with emphasis on the gqa enhancements in mged and the new coil shape tool |
| 18:02.09 | CIA-40 | BRL-CAD: 03brlcad * r34102 10/brlcad/trunk/TODO: there is a coil tool now, but needs a manual page |
| 18:29.59 | starseeker | brlcad: ok |
| 18:31.13 | starseeker | brlcad: um. there's a coil.xml file that should be creating a coil man page |
| 18:35.23 | starseeker | um - is anyone else not able to svn co the brlcad tree? |
| 18:37.11 | madant | update working for me :) |
| 18:40.13 | starseeker | growl |
| 19:18.24 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 19:25.12 | *** join/#brlcad dreeves (n=dreeves@67.130.253.14) | |
| 19:30.43 | brlcad | starseeker: ah! okay |
| 19:31.15 | brlcad | just noticed all the .1's in src/shapes and it seemingly missing for that one |
| 19:31.26 | brlcad | side effect of having a separate doc dir |
| 19:32.39 | CIA-40 | BRL-CAD: 03brlcad * r34103 10/brlcad/trunk/TODO: coil has a manual page, just in doc/docbook give it's new-style |
| 20:24.47 | *** join/#brlcad andax (n=andax__@d213-102-41-199.cust.tele2.ch) | |
| 21:07.39 | *** join/#brlcad madant (n=d@117.196.139.99) [NETSPLIT VICTIM] | |
| 21:07.39 | *** join/#brlcad MinuteElectron (n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT VICTIM] | |
| 21:07.39 | *** join/#brlcad pacman87 (n=pacman87@resnet-46-40.dorm.utexas.edu) [NETSPLIT VICTIM] | |
| 21:07.39 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) [NETSPLIT VICTIM] | |
| 21:26.49 | *** join/#brlcad MinuteElectron (n=MinuteEl@unaffiliated/minuteelectron) | |
| 21:30.19 | *** join/#brlcad pacman871 (n=pacman87@resnet-46-40.dorm.utexas.edu) | |
| 21:41.45 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) | |
| 22:21.27 | brlcad | waves to pacman87, wb |
| 22:21.35 | starseeker | arrrrrrgh |
| 22:21.44 | starseeker | why can't I connect to the sf server?? |
| 22:21.55 | starseeker | upgraded to 1.6.0 even |
| 22:22.05 | pacman87 | waves back |
| 22:22.58 | brlcad | starseeker: sf doesn't like you |
| 22:23.38 | starseeker | apparently |
| 22:23.44 | starseeker | svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 22:23.48 | starseeker | svn: OPTIONS of 'https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk': could not connect to server (https://brlcad.svn.sourceforge.net) |
| 22:24.28 | brlcad | works here |
| 22:25.53 | starseeker | ok, it's some sort of general failure |
| 22:27.19 | starseeker | checks how subversion was built |
| 22:38.17 | ``Erik | hrm, issues connecting to bz, issues connecting to sf, ... hrmmmm |
| 22:39.14 | ``Erik | though I do vagually recall seeing 'OPTIONS' related errors connecting to an svn server being due to a proxy that doesn't pass the 4 or so extensions |
| 22:40.21 | brlcad | ah, good point -- starseeker, they changed some of the http/webdav negotiation in 1.6.0 .. supposedly to require much fewer connections and speed everything up |
| 22:40.30 | brlcad | might have introduced a bug for some network/sever configurations |
| 22:48.47 | starseeker | brlcad: more likely I did something to my system in that last upgrade |
| 22:51.41 | starseeker | grits his teeth and runs revdep-rebuild |
| 23:06.13 | *** join/#brlcad pacman87 (i=500@resnet-46-40.dorm.utexas.edu) | |
| 23:17.17 | starseeker | oh, cute: http://bugs.gentoo.org/show_bug.cgi?id=263497 |
| 23:20.32 | starseeker | now I get to upgrade the friggin kernel |
| 23:21.48 | brlcad | heh |
| 23:22.07 | brlcad | or downgrade glibc ;) |
| 23:22.39 | brlcad | i'm sure you could manually hack the build to make it work, it's just that socket() call getting a bad enum value |
| 23:22.51 | starseeker | oh, sure |
| 23:23.08 | starseeker | but if I'm going to start getting grief for running an old kernel, might as well update it now |
| 23:24.49 | brlcad | seems pretty obscure, specific to a networking code that is already using updated glibc interface with a specific socket option |
| 23:25.19 | starseeker | hopes we won't see this sort of grief if/when we use subversion in the geometry server |
| 23:25.56 | brlcad | curious, which enum(s) is 0x80001 ? |
| 23:26.18 | brlcad | (look in /usr/include/sys/socket.h) |
| 23:27.40 | brlcad | might be easier to look at svn's sources and find that select() call |
| 23:28.10 | brlcad | er, s/select/socket/ |
| 23:28.36 | ``Erik | hugs bsd for providing a unified cohesive system with some great release engineering :D |
| 23:29.49 | starseeker | don't see 0x80001 in that file |
| 23:29.57 | starseeker | opps |
| 23:30.03 | starseeker | has to vacuum now |
| 23:30.33 | ``Erik | I'd guess that's a combination of flags |
| 23:30.42 | ``Erik | or'd together |
| 23:33.36 | brlcad | looks like the neon library is actually the one to blame with the socket() call |
| 23:35.21 | brlcad | aha, found it |
| 23:35.28 | brlcad | they're using SOCK_CLOEXEC, new flag |
| 23:35.39 | brlcad | instead of just SOCK_STREAM |
| 23:39.14 | brlcad | ah, which is the high 0x80000 bit, so if it was just 0x1, it'd work just fine |
| 23:39.34 | brlcad | returns to coding, content |
| 23:40.23 | ``Erik | coding, not migrating machines? :D *duck* |
| 23:47.15 | brlcad | absolutely, this is a coding weekend |
| 23:47.24 | brlcad | planned |