Back
[00:32:57] <tomp> dmess: i really havent used it enough to teach, but read the manual, JMK did an excellent explanation ( i could work thru the examples and see it work, so can you)
[00:33:10] <tomp> just go thru it slow
[01:05:44] <dmess> i'll try it.. i NEED it so i gotto
[01:06:25] <dmess> see if i can get a lesson on a regular scope tomorrow
[01:19:03] <tomp> a scope is just a way to visualize electrical stuff. you can see if its bigger smaller or faster slower. you get 2 rulers to measure with, up down is bigger smaller (volts usually) and left right is time. so you can see what changed & when.
[01:19:20] <tomp> its just like a vernier or micrometer or thermomenter
[01:20:21] <dareposte> but with lots more buttons
[01:20:59] <dareposte> dmess: did you ever get one of those cnc4pc boards?
[01:22:44] <tomp> you jumped to another thought, no never used/had one
[01:23:40] <tomp> maybe back later, traveling home now, try the halscope tutorial, it's actually fun.
[01:23:40] <dareposte1> dareposte1 is now known as dareposte
[01:28:21] <dmess> i have the speed controler and spindle index pulse cards in transit... SEE what I get
[01:29:41] <dmess> hopefully an early x-mas
[04:51:52] <eric_u1> anyone ever use vpnc? I can't get it to read a .conf file
[04:56:16] <JymmmEMC> I've used VNP, and VPN, never heard of vpnc
[04:56:24] <JymmmEMC> VNC
[04:56:45] <eric_u1> linux vnc
[04:56:51] <eric_u1> sorry vpn
[04:57:09] <JymmmEMC> ok, which one now? =)
[04:57:16] <eric_u1> trying to get past a firewall using vpn
[04:57:30] <JymmmEMC> you using NAT on your network?
[04:58:03] <eric_u1> penn state firewalls most useful computers
[04:58:14] <eric_u1> have to log into their vpn to get there
[04:58:30] <JymmmEMC> you using NAT on your network?
[04:58:35] <eric_u1> yes
[04:59:05] <JymmmEMC> then enable vpn passthru on it
[05:02:13] <eric_u1> man page for vpnc says you can enter "vpnc filename" and vpnc will look for "filename.conf" but it doesn't
[05:02:39] <JymmmEMC> eric_u1: Do you have a router?
[05:03:36] <eric_u1> yes
[05:03:47] <JymmmEMC> then enable vpn passthru on your router
[05:04:10] <eric_u1> my problem is more along the lines of "vi somefilename.txt" and it never finds somefilename.txt no matter what
[05:04:54] <eric_u1> but it appears that vpn passthrough is enabled
[05:06:18] <JymmmEMC> maybe vpmc /path/to/filename
[05:06:49] <eric_u1> well, it works if I rename my file default.conf, but man page says I don't have to do such an ugly thing
[05:07:32] <JymmmEMC> well if it works, do it
[05:17:10] <eric_u2> good news is it worked, bad news is it wouldn't connect to the subnet I needed
[05:17:24] <eric_u2> so I'm still firewalled out of my computer :(
[05:38:28] <eric_u2> didn't even notice that I changed names
[09:12:08] <fragalot_> :o
[09:12:34] <fragalot_> it's possible that my school might donate the pc for my machine
[09:12:44] <fragalot_> awesome o.O (still pending on that suggestion tho)
[09:24:41] <archivist_ub> a supplier of frame extrusion
http://www.minitecframing.com/ also in uk Im still looking for a better supplier I saw at a show
[09:24:57] <archivist_ub> bah he wented again!!
[09:48:10] <archivist_emc> hmm bug in gcode parser "G0 X#<curve1_xstart> #<curve1_ystart> z.5 (move to cut start)" error message says missing = where the real error is missing Y
[10:10:30] <alex_joni> archivist_emc: bug lerman_ :)
[10:11:50] <archivist_ub> took me a while to spot the error as the message was sending me off!
[10:12:16] <alex_joni> archivist_emc: the proper way to deal with this is to submit a bug report at SF
[10:15:18] <archivist_ub> I know but the lurkers in here may say not a bug, expected modal behaviour
[10:47:27] <alex_joni> well.. you can't expect it to say Y
[10:47:41] <alex_joni> but you can expect that it says modal operator or whatever missing
[10:47:49] <alex_joni> s/modal//
[10:48:04] <alex_joni> although.. hmm
[10:48:15] <alex_joni> I think it might even be right
[10:48:25] <alex_joni> you have: G0 X<var> <var>
[10:48:33] <alex_joni> it would expect a <var>=value
[10:48:44] <alex_joni> I think it's right as it is..
[10:53:21] <archivist_ub> I wonder if <var>=etc should not be after/in the middle of a move to stop ambiguity like that
[11:25:57] <alex_joni> not sure if it's allowed in the same block, but I think it might be
[11:27:51] <archivist_ub> just found a real parser bug
[11:28:55] <archivist_ub> damned silly thing wont allow a copy from a msg popup can only get a screen grab
[11:29:33] <cradek_> I think they also go to stderr
[11:29:47] <cradek_> cradek_ is now known as cradek
[11:31:52] <archivist_emc> * archivist_emc types the words "near line 52 of x.ngc Named parameter not defined" er what named parameter!
[11:38:51] <archivist_emc> as the parser had to lookup the parameter, it knows the name it failed to find so should be in the error message
[12:02:04] <fragalot> I just had a lil' idea for the USB version of this,.. Just make the controller handle some of the feedback things if it can, such as the home or limit switches, so it can take action before the PC is able to receive that info
[12:02:14] <fragalot> archivist_ub: ^
[12:03:25] <archivist_emc> nah just get the usb comms deterministic and fast as thats required for the servo loops
[12:03:27] <fragalot> have the USB also tell the controller how /FAR/ it wishes to move, (eg. instead of "step.. step", just say 15 steps."
[12:03:56] <fragalot> archivist_ub: problem is just the massive latency USB has
[12:04:13] <fragalot> esp. with communication from the machine to the host,.. always waits for the host to REQUEST the data :/
[12:04:23] <archivist_emc> standard usb has latency yes
[12:04:31] <fragalot> most problems could be solved by making the controller smarter i'd say
[12:04:40] <archivist_emc> hence the req is in the realtime part :)
[12:04:52] <fragalot> yeah
[12:05:20] <fragalot> that's why i'm suggesting to like,.. not make the PC itself realtime, just have the controller take action :p
[12:05:55] <fragalot> granted, it's a challenge
[12:06:00] <fragalot> REAL challenge ;)
[12:06:18] <fragalot> but, in the computer world, nothing is impossible
[12:06:52] <archivist_emc> see what parts get moved to the mesa fpga and do similar
[12:07:01] <fragalot> yeah
[12:08:27] <fragalot> the home & limit switches can easilly be done on the fpga, so can the homing process..
[12:09:08] <fragalot> the problem would be making it do complex curves as USB won't let you move the axis independantly at different rates as easilly as a parport does
[12:09:41] <fragalot> unless if you program the movement into the FPGA's memory module first.. :/
[12:09:45] <alex_joni> fragalot: if you want to spend energy .. better use a RT-ethernet connection
[12:09:48] <alex_joni> like Ethercat
[12:10:23] <fragalot> alex_joni: but how will you waste your time on youtube while the machine is running if you do it that way ;)
[12:10:35] <archivist_emc> hmm that would be nicer cabling
[12:12:01] <fragalot> yeah
[12:12:03] <archivist_emc> escape key doesnt work when a debug window is waiting for a click! potential damage
[12:12:45] <fragalot> archivist_ub: that's to boost the economy
[12:14:07] <archivist_emc> * archivist_emc begs for debug and msg to go to a scrolled window in axis so focus remains safe
[12:16:15] <fragalot> aah, vmware won't boot completely, it's taking ages
[12:25:54] <alex_joni> fragalot: second eth?
[12:26:20] <alex_joni> archivist_emc: that's already implemented in pre-2.3
[12:26:49] <archivist_ub> er what Im 2.2.6
[12:27:31] <fragalot> alex_joni: that'd work on mobo's that have that, my issue is that i can't add the hardware I need to my boxes, would have the same issue with eth :p
[12:33:29] <alex_joni> fragalot: USB-eth ?
[12:33:44] <alex_joni> not for the RT link though, but should be fine for youtube
[12:34:31] <fragalot> gotta run
[12:34:37] <fragalot> alex_joni: True
[12:34:39] <fragalot> bbl
[12:35:42] <jepler> archivist_emc: in the development version of emc, here's what axis does with errors and operator messages:
http://emergent.unpy.net/files/sandbox/notifications.png and
http://emergent.unpy.net/files/sandbox/multiple-notifications.png
[12:36:56] <archivist_ub> jepler I thought a scrolling box would suit best
[12:37:25] <jepler> hm, this little plug-in power supply with a USB jack measures about 5.6V, and that's with over 30mA of load. maybe it's not so great a way to power a homebrew USB device for testing without endangering a computer's USB port
[12:38:01] <archivist_ub> 5.6 is somewhat over!
[12:38:09] <jepler> yep
[12:38:55] <SWPadnos> do you connect both the power supply and the computer at the same time?
[12:39:58] <jepler> SWPadnos: no -- this is just for smoke testing, it can't communicate with the computer this way
[12:40:49] <SWPadnos> ah - ok. I had misunderstood your concers there
[12:40:50] <archivist_ub> may get a valid smoke test
[12:41:01] <jepler> (but still 5.6V is within the absolute maximum ratings of the at90usb162, so it shouldn't cause damage)
[12:41:07] <SWPadnos> 5.6V shouldn't hurt anything on most microcontrollers
[12:41:19] <jepler> oh well
[12:41:20] <SWPadnos> if you see smoke, get a different power supply ;)
[12:41:32] <jepler> still leaves me scratching my head about why this board is flaky
[12:41:50] <SWPadnos> what's it (not) doing?
[12:42:42] <jepler> on monday it wouldn't even show its power LEDs. today it does (without me changing anything) except one of the 4 LEDs on it seems to be damaged (it doesn't light).
[12:42:55] <jepler> oh well, I should head to work instead of playing with my hobby projects
[12:43:00] <SWPadnos> heh
[12:43:08] <SWPadnos> bring the hobby project to work ;)
[12:43:13] <archivist_ub> hobby is more fun
[12:43:27] <jepler> archivist_ub: believe me, I know it
[12:43:41] <archivist_ub> same here :)
[12:44:12] <archivist_ub> Im playing with EMC as a slight work excuse
[12:44:38] <archivist_ub> would be faster to get a hacksaw and file out
[12:45:47] <jepler> http://emergent.unpy.net/files/sandbox/tqfpboard-schematic.png <-- here's my board -- USB, microcontroller, LEDs, and some I/O on headers. no specific use in mind, just to experiment with this new-to-me microcontroller family at90usb
[12:45:51] <jepler> anyway, bbl
[13:00:41] <fenn> did you pay for the usb developers software? iirc it's necessary to use the usb functions
[13:02:51] <jepler> fenn: no. there's USB software available under the MIT license from here:
http://www.fourwalledcubicle.com/MyUSB.php
[13:03:43] <jepler> to make a "real product", I think that you may need to pay for an allocation of a vendor/product number. this doesn't matter much to me
[13:04:23] <jepler> for a bit more on that:
http://www.fourwalledcubicle.com/files/MyUSB/Doc/1.5.2/html/page_vidpid.html
[13:04:51] <fenn> thanks for the links /me looks
[13:05:28] <jepler> I haven't actually uploaded any firmware with a usb function to the device yet (aside from the bootloader, which is preprogrammed)
[13:05:40] <archivist_ub> hmm interesting /me contemplates usb IEE488 controller
[13:06:20] <fenn> it comes with a usb bootloader? (from digikey?)
[13:06:55] <jepler> fenn: the at90usb162 (and I think other parts in that family) are preprogrammed with a "DFU bootloader" which can transfer a new firmware over USB -- no need for the 6- or 10-pin programming header and a special cable
[13:07:04] <fenn> neat
[13:08:10] <jepler> fresh from the factory it automatically enters the bootloader. after that, if you haven't modified the fuse settings, you can enter it by having a specific pin brought low when reset goes high; I think that you can also include a jump to a specific address to enter the bootloader from your own firmware
[13:08:36] <jepler> the downside is that the bootloader takes away 4k (?) of program space
[13:09:06] <jepler> bbl
[15:49:08] <tomp> is there a place in emc where the gcode is parsed into structs? (eg lnum gcode x y z u v w a b c i j k mcode... )
[15:51:27] <SWPadnos> in the interpreter ;)
[16:09:15] <archivist_ub> * archivist_ub is beginning to hate the center format arc with a vengeance
[16:15:14] <BigJohnT> why is that archivist_ub?
[16:16:03] <archivist_emc> hand coding end points and debugging
[16:16:25] <BigJohnT> You don't use the g code wizard for arcs?
[16:16:58] <archivist_emc> what wizard
[16:17:36] <BigJohnT> Arc Buddy here
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_EMC_G-Code_Generators
[16:18:58] <archivist_emc> my arcs are connected not on nice angles/coordinates
[16:19:49] <cradek> archivist_emc: I usually end up drawing them in cad ... I agree it's a big pain to hand generate them
[16:20:03] <BigJohnT> they don't have to be connected ...
[16:20:34] <archivist_emc> er but its the shape :)
[16:23:50] <archivist_emc> cradek: so would I but when in EMC I cant get at windaz for cad
[16:26:42] <BigJohnT> archivist_emc what kind of shape?
[16:27:03] <archivist_ub> just a mo
[16:28:39] <archivist_ub> http://www.archivist.info/cnc/p1010246.jpg hour detent (pic on its side)
[16:29:41] <cradek> haha, fractions
[16:30:35] <archivist_ub> the drawing has a large amount of guess work!
[16:30:44] <cradek> and let me just say that I don't really understand the drawing at all (but probably very clear with the part in front of you)
[16:30:50] <cradek> yes it sure does
[16:31:05] <archivist_ub> just remaking parts that are missing or made so badly
[16:31:17] <archivist_ub> this one is missing
[16:31:28] <cradek> yuck
[16:32:12] <archivist_ub> well the one in the clock was nothing like (worked the wrong side of the pins)
[16:51:47] <BigJohnT> archivist_ub is that a progressive arc like a french curve?
[16:52:12] <archivist_emc> Im treating as simple arcs
[16:52:35] <skunkworks> BigJohnT: your running trunk on your plasma that blends arcs (like it already does with lines?)
[16:52:49] <BigJohnT> Yes :)
[16:52:56] <anonimasu> :D
[16:52:59] <skunkworks> ok - did you see the post on cnczone?
[16:53:00] <anonimasu> does that work faster?
[16:53:19] <BigJohnT> me? yes
[16:53:30] <BigJohnT> post no
[16:53:30] <fenn> why not just use R format arcs
[16:53:43] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=65515
[16:53:45] <fenn> erfm scrollback underflow error
[16:53:58] <anonimasu> fenn: because they are less precise..
[16:54:09] <anonimasu> * anonimasu loves the heidenhain rnd command
[16:54:14] <fenn> underconstrained, not less precise
[16:54:30] <fenn> but usually it seems to do the right thing
[16:55:31] <anonimasu> I like doing L x10 RND 5 L y20 and get a round corner
[16:55:51] <BigJohnT> the Arc Buddy kinda does the conversion for you from R to center format...
[16:56:30] <toastatwork> in soviet russia, arcs format _you_
[16:56:56] <archivist_emc> and in the UK atm
[16:57:49] <toastatwork> blending... of the people!
[16:59:08] <BigJohnT> skunkworks: I thought the arc line arc blending was on 2.2.6?
[16:59:34] <cradek> do not confuse blending with the naive-cam detector
[16:59:43] <cradek> lines and arcs have always blended with one another (no stopping)
[16:59:48] <BigJohnT> I stay confused some time
[17:00:22] <cradek> the new code eliminates unnecessary tiny tiny arcs that some cam systems generate (why?) if they do not affect the path according to the given tolerance
[17:00:43] <BigJohnT> was that in trunk only?
[17:00:59] <cradek> this is really not going to be an issue with archivist_emc's hand-generated code
[17:01:09] <cradek> BigJohnT: probably, but I'd have to look to be sure
[17:01:29] <BigJohnT> no I was answering the post that skunkworks posted on cnczone
[17:01:55] <cradek> oh sorry
[17:02:10] <dushantch> cradek: is it possible to make a script that will run EMC simulator on some G-code, and when it fails on Rtool>Rcorner, it will make an arc dith R=Rtool of that corner in g-code, and so on and in the end it will output new G-code for review and report : "I've rounded 20 corners, please check"?
[17:02:25] <dushantch> s/dith/with
[17:02:47] <cradek> dushantch: anything is possible, including that
[17:02:50] <BigJohnT> that skunkworks pointed me too not posted
[17:03:59] <dushantch> cradek: ok, but is it a good solution, as it doesn't change interpreter, and it's easily checked in simulator, and done only once?
[17:04:54] <dushantch> with simulator I meant in some other sw
[17:05:26] <cradek> ah, I sensed that "is it possible" wasn't the question you really wanted me to answer :-)
[17:05:37] <cradek> personally I don't think it's a good fix for the problem
[17:05:43] <dushantch> :)
[17:05:54] <dushantch> well I had to make an intro of some kind :)
[17:06:00] <cradek> for one thing, parsing gcode is hard
[17:06:19] <cradek> but parsing it exactly the same way emc's interpreter does it is easy - you just use emc's interpreter
[17:06:58] <cradek> which points us to the better solutions - which are some variations of "fix the interpreter to do what you want"
[17:07:02] <dushantch> that's why I thought this would be easy, as it uses current interpreter
[17:07:49] <cradek> sorry, I don't see any advantage to your solution, only unnecessary complexity
[17:08:07] <anonimasu> isnt it better to write proper g-code in the first place?
[17:08:16] <tomp> yes parsing depends on the gcode 'variety'
[17:08:20] <dushantch> but the problem is that machine makes decisions then, and how do we now that they're correct?
[17:08:40] <cradek> by programming it to make the correct decisions
[17:08:50] <dushantch> how can we check it without running the real machining?
[17:08:51] <lerman_> did someone call my name?
[17:08:54] <fenn> anonimasu: writing proper g-code is a lot more (unnecessary) work in this case
[17:09:08] <dushantch> fenn: true
[17:09:09] <cradek> lerman_: duck and cover
[17:09:23] <dushantch> cradek: you idealist :)
[17:09:35] <lerman_> Not a bug. The parser can't read your mind.
[17:09:58] <archivist_emc> should be able too by now
[17:10:08] <anonimasu> fenn: uh..yeah tool radius > corner radius is alot of work.
[17:10:11] <cradek> if someone wants emc to accept concave corners for compensation, he/she should continue work on the concave_ccomp branch I started. The work is partly done. IMO, other hackery to work around it is wasted effort.
[17:10:14] <dushantch> Murphy says that when you program something to make correct decisions., it'll do the oposite, but only when you're not looking/when it costs a lot :)
[17:10:14] <anonimasu> err <..
[17:10:15] <lerman_> (Although I have to admit, that it didn't have a very good guess).
[17:10:33] <fenn> anonimasu: it is, you have to add an arc for every concave corner
[17:11:14] <tomp> where is some description of the concave_ccomp branch?
[17:11:22] <cradek> I have very little patience for continuing to argue about whether it's good/bad/necessary/unnecessary
[17:11:28] <anonimasu> I dont even know what a concave corner is.
[17:11:32] <cradek> when that happens I just go do something else...
[17:11:34] <dushantch> and I propose that adding of arc to be a new g-code which can be reviewed, and run on other machines with same results
[17:11:39] <fenn> anonimasu: g1 g1 where angle is < 180
[17:11:50] <anonimasu> ah.. I see..
[17:11:55] <dushantch> cradek: I don't want to argue, I just ask
[17:11:56] <cradek> fenn: not right. arcs-line and arc-arc make concave corners too.
[17:12:05] <tomp> 'inside/outside' corners depends on the direction you follow the path (more common term)
[17:12:08] <cradek> all of line-arc arc-line arc-arc line-line can make a concave
[17:12:14] <anonimasu> does that break the interp?
[17:12:22] <anonimasu> if you use tool comp?
[17:12:31] <cradek> anonimasu: depends on what you call "break"
[17:12:41] <SWPadnos> no, your program doesn't run if you have an inside corner when using cutter comp
[17:12:48] <cradek> they describe a shape that cannot be cut, so you get an error (currently)
[17:12:51] <anonimasu> break I mean give you a error message about it and stop cutting..
[17:12:56] <cradek> yes
[17:13:13] <cradek> that is by design
[17:13:21] <lerman_> If the interp is asked to do something that is impossible, it stops.
[17:13:26] <dushantch> so what with concave lines made of lot of small lines?
[17:13:27] <cradek> I would like a different design, and have already written most of it
[17:13:51] <archivist_emc> ugh so I need to rewrite with hand compensation
[17:14:09] <cradek> archivist_emc: not if you describe a path that can be actually cut
[17:14:12] <cradek> bbl, lunch
[17:14:19] <dushantch> Like making a mould from output of some CAM sw?
[17:14:35] <tomp> where is some description of the concave_ccomp branch? wiki has the word concave just twice.
[17:14:38] <dushantch> cradek: sorry if I bug you :)
[17:14:50] <lerman_> The CAM software should be smart enough that it isn't a problem.
[17:14:52] <BigJohnT> whats for lunch cradek ?
[17:15:40] <dushantch> lerman_: afaik not in real life , and not with some stupid people writing postprocessors
[17:15:57] <archivist_emc> for use cheapskates emc is the nearest to cam we can get
[17:16:14] <anonimasu> the solution is to add a rounding g-code like on heidenhain controls.. so you can round corners, with a parameter ;) rnd tool radius
[17:16:33] <anonimasu> :p
[17:16:40] <anonimasu> * anonimasu hides
[17:17:02] <dushantch> anonimasu: and I propose that it should be done with a script which check all the places where interpreter bails out
[17:17:05] <lerman_> No, the solution is to find someone with appropriate skill who cares enough about this to implement a change.
[17:17:06] <fenn> i think this is called g02 or g03
[17:17:38] <anonimasu> yeah and then you need to work out where the arc and line intersects..
[17:17:46] <lerman_> (notice I said "change" not "fix")
[17:17:56] <fenn> anonimasu: actually that does seem quite handy
[17:18:36] <tomp> how to browse cvs?
[17:18:36] <anonimasu> I think throwing in a RND command between the two lines to round the corner is quire neat.. no calculations or anything requires..
[17:18:45] <anonimasu> required..
[17:18:54] <fenn> tomp:
http://cvs.linuxcnc.org/cvs/
[17:18:59] <tomp> thx fenn
[17:19:40] <fenn> see the pulldown below the file list with branch names?
[17:20:10] <fenn> not sure how to get diffs between branches though
[17:20:46] <SWPadnos> adding RND is a non-trivial task on several levels
[17:21:07] <SWPadnos> not least of which is that the interpreter only deals with single-letter codes at the moment
[17:21:08] <lerman_> I've written gcode subroutines that: given three points defining non-colinear line segments and given a radius, converts them to two line segments with an arc connecting them.
[17:21:09] <dushantch> when you selest a file you have a option to diff it
[17:21:09] <anonimasu> probably
[17:21:44] <SWPadnos> so that would look like an R with no parameter, an N with no parameter and not at the beginning of a line, and a D with no parameter - all of which are at least one error
[17:21:59] <dushantch> but what if arc is so large that the second line would be <0
[17:22:06] <SWPadnos> unless you change the interp to use spaces as delimiters, which would have other implications
[17:22:15] <lerman_> It gives an error.
[17:22:19] <anonimasu> dushantch: then it errors
[17:22:23] <dushantch> ok
[17:22:31] <SWPadnos> bbl
[17:22:35] <anonimasu> or if you dont define a tool it'll cut it
[17:22:47] <anonimasu> like tool tip on path..
[17:22:49] <lerman_> I would rather add a -R parameter to g1.
[17:23:01] <anonimasu> round to the next line
[17:23:42] <dushantch> I know, it would be nice
[17:24:07] <anonimasu> the heidenhain control's has lots of neat stuff.. for doing hand programming
[17:24:10] <tomp> fenn: sorry i see no pulldown below file list with branch names . theres a File and a General Options area.
[17:24:49] <dushantch> tomp: there's: "Show only files with tag:"
[17:24:59] <dushantch> above general options
[17:31:42] <tomp> please, where? (i've even text searched for 'files' and 'branches' )
http://imagebin.org/27776
[17:33:16] <fenn> eh sorry you have to click on emc2 first
[17:34:18] <tomp> thx. got to concave_comp now
[17:36:12] <fenn> i think this is what was changed:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/rs274ngc/interp_convert.cc.diff?r1=1.106;r2=1.106.4.9;only_with_tag=concave_comp
[17:38:33] <tomp> thx fenn
[19:33:10] <fragalot> my agenda is now officially full.. I had to put post-it's in, and put post-it's ontop of the other the post-it's
[19:34:10] <archivist_ub> real computing, using a stack
[19:34:32] <fragalot> Exactly
[19:35:20] <anonimasu> :)
[19:35:49] <fragalot> *g* the hammer drops on 19 october
[19:35:58] <fragalot> then the school board decides if i should get a free PC from them or not
[19:36:07] <archivist_ub> hmm does quicksort work on post-it's
[19:36:17] <fragalot> archivist_ub: not even bubble sort works
[19:36:19] <archivist_ub> or shellsort
[19:36:30] <archivist_ub> filesort ftw
[19:36:40] <fragalot> xD
[19:46:08] <alex_joni> archivist_ub: simplesort works
[19:46:32] <alex_joni> but by the time you finished sorted, the post-it's probably won't stick anymore
[19:46:33] <archivist_ub> gets stuck to the fingers
[19:48:49] <archivist_ub> add btree index to the post-its
[19:54:30] <alex_joni> heh
[19:54:40] <alex_joni> or avl.. should be good enough
[19:55:53] <fragalot> Just try & filter out the middle one if you nolonger need it
[19:56:01] <fragalot> >.< then realize you forgot what date it was stuck to
[19:56:28] <archivist_ub> methinks doubly linked list
[19:57:01] <anonimasu> lol
[19:57:12] <anonimasu> that's some fancy post-it's
[19:57:14] <fragalot> messylist is the function I used.
[19:57:54] <alex_joni> this page is really cool:
http://www.sortieralgorithmen.de/bubblesort/index.html
[19:58:08] <alex_joni> I've never pictured sorting algorithms in such a visual way
[19:58:16] <alex_joni> (bubblesort is really bubbly :D)
[19:58:37] <fragalot> lmao
[19:59:45] <fragalot> v3 looks nice
[20:00:01] <fragalot> speed-wise
[20:01:12] <alex_joni> MSsort is quite fast :)
[20:05:34] <fragalot> I never knew there were so many sorting algos :p
[20:06:49] <alex_joni> well.. it's a simple problem you need to solve :)
[20:06:56] <alex_joni> there are still a couple missing :D
[20:06:59] <anonimasu> lol
[20:08:16] <fragalot> :p
[20:08:20] <fragalot> GNITE!
[20:09:51] <archivist_ub> I think some have multiple names tapesort->filesort
[20:11:21] <alex_joni> it's nice to see how they work on reverse ordered
[20:18:15] <alex_joni> lol, shearsort is the nicest to look at
[21:38:01] <Jono2> I solved the Problem with image to gcode
[21:39:00] <Jono2> it were, as you thought missing libarys
[21:42:02] <Jono2> thanks for pushing me in the right direction
[21:48:59] <tomp> heh the stoogesort (nyuk nyuk nyuk)
http://cg.scs.carleton.ca/~morin/misc/sortalg/
[21:51:08] <dmess> hi all
[21:54:57] <[1]a-l-p-h-a> [1]a-l-p-h-a is now known as a-l-p-h-a1
[22:06:19] <alex_joni> good night all
[22:26:20] <dmess> hi all
