nfk

Activity Graph

Page 1 of 12 | Next »

2019-02-28

[13:31:57] nfk: has joined #ruby
[15:52:01] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-02-09

[20:11:12] nfk: has joined #ruby
[22:40:55] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-02-07

[13:39:02] nfk: has joined #ruby
[20:33:03] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-02-05

[14:39:14] nfk: has joined #ruby
[15:00:10] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-02-04

[19:17:10] nfk: has joined #ruby
[19:18:13] nfk: what's a neat and functional way to handle nil being passed to a lambda?
[19:18:57] nfk: i could check for it either before calling it or i could check for it within but i wish there was a cleaner way like not treating nil as a valid argument
[19:22:12] nfk: even if i control the calling code?
[19:23:12] nfk: and wouldn't raising an exception be considered a type of side-effect?
[19:43:21] nfk: after reading some more theory and discussion on it, I think i prefer to just let the exception propagate to a higher level and let that sort out why it got that exception
[19:49:02] nfk: i'm aware of it but 1) i'm not really doing OOP and 2) when you get an exception during I/O, chances are you actually need to do something about it rather than make it go on
[20:03:18] nfk: havenwood, i was originally trying to figure out how to handle a situation where ARGV[0] is nil i.e. not passed to the program
[20:03:53] nfk: i ended up just calling the lambda with nil and then doing rescue with if statements in the calling code
[20:05:54] nfk: havenwood, wait, is the only difference use of arg: over (arg) in the lambda definition?
[20:08:31] nfk: there's so much new stuff, that it boggles my mind :D
[20:11:29] nfk: havenwood, could it be a fairly new feature or did i just incorrectly recreate your example - i'm getting NoMethodError regarding calling compact on Hash object
[20:17:37] nfk: yup, i'm currently testing on 2.3 while developing with 2.6
[20:18:02] nfk: gentoo somehow managed to fubar irb with 2.6 and i really can't be bothered to dive into how exactly they did it
[20:18:39] nfk: all i can say is that generally the code works but there's some weirdness with search path for module loading which only breaks irb
[20:20:17] nfk: i'm very certain that irb never was part of ruby package - it's just that the loader logic has changed compared to 2.3 and maybe 2.5 (if i still had that around when I did the initial investigation part) and as I said, the logic executes but fails to find the module even though it's still installed
[20:21:11] nfk: nothing else seems to be affect and this is the first syntactical difference I have encountered, so it wasn't really anywhere near my priority list of things to do
[20:23:38] nfk: oh, right, it might be that it's not even path but parsing of module version (even though the appropriate one is installed) - it just complains that it failed to find a module that fits the requirements
[20:24:04] nfk: and I really didn't have any will or need to dig into it any deeper as to what was going on
[20:33:56] nfk: the horrors of what code like that can do
[20:37:09] nfk: i just feel put off by the fact that while it's purposely constructed, that you're effectively doing computation with what is "non-value" or falsity
[20:37:30] nfk: it's the modern day equivalent of dividing by 0
[20:40:02] nfk: as in static? that is not possible in the first place
[20:42:25] nfk: havenwood, ah, so much for works anywhere - doesn't work even on i386, much less aarch64
[20:48:36] nfk: You must delete the prior rubyc or your squashfs will continually grow larger and the embedded squashfs compile time will be very, very long. // what is this? bash oneliner? ...
[20:49:40] nfk: also, this will not produce cross-platform binaries, i bet
[20:54:44] nfk: havenwood, personally i do not find it so impressive other than wondering how it even works (which i'm currently trying to find out)
[20:54:57] nfk: not that i'd ever want to compile ruby
[20:55:00] nfk: so stupid
[20:56:56] nfk: not to be a haughty bastard but my CPU from 2006 (or so) is currently under less than 10% load while running an irc chat client, a full compositing desktop and a modern browser with youtube open
[20:57:44] nfk: i expect a 2018 ipad pro to outperform this device (at least in short bursts and if you're not too concerned about also heating your room with it)
[20:58:14] nfk: havenwood, i meant, there's so much power in modern hardware that SPEED is hardly a concern
[20:58:28] nfk: some really crazy stuff notwithstanding
[21:04:16] nfk: well, you can can't really beat hand-written assembly or so i hear
[21:04:52] nfk: i just wonder if anyone has ever written a fully working application server in asm
[21:05:23] nfk: in fact, i bet you could reduce the power requirements by an order of magnitude if you could do that with pure CUDA XD
[21:08:57] nfk: phaul, i find the notion of running an os on a GPU a bit disconcerting
[21:12:49] nfk: cahoots, you might be missing that Java by default compiles to its own bytecode - i suspect that it could be compiled into final architecture form but i'm not quite sure and whatever i can gather from those benchmarks, it looks like normal Icedtea implementation of Java, which is compiled to Java bytecode not machine code
[21:14:12] nfk: and C/C++ SPEED comes with caviats of using horrible languages with often unsafe memory access which makes them fast and prone to bugs unless the programmer is a true master
[21:15:33] nfk: phaul, i see. was that in OpenCL or mantel?
[21:19:57] nfk: cahoots, generally the performance critical parts are written in C/C++ even in Ruby but a lot of things can be made faster (or a lot slower, if you will) even in just pure Ruby which in its own right is one of the slowest widely used languages
[21:20:41] nfk: similarly to how C/C++ will use asm or compiler intrinsics to optimize performance critical sections in a lower level language than themselves
[21:21:54] nfk: i compile most of my code at O1 level because most of it will never be executed at all or once in a blue moon
[21:26:29] nfk: cahoots, it's not really my place to say it but if you are concerned with CPU cycles being burnt, you are likely making a mistake by using cloud provider before you are big enough to not care about costs
[21:27:48] nfk: i assure you that most happy ruby users do not give a toss about performance
[21:28:11] nfk: the rest are not using an alternative implementation for their needs
[21:29:36] nfk: like my latest "finished" code was using the built-in OpenSSL engine and mongodb client with native extensions to crunch and store hashes of tens of gigabytes of data - didn't take even an hour for basically hobby project
[21:30:10] nfk: and probably a lot less than an hour but i literally did not care enough to bother even timing it
[21:31:04] nfk: and, fun fact, the limiting factor was HDD I/O speed even with RAID10
[21:34:55] nfk: crystal is a different language and it's not production ready
[21:34:59] nfk: use it at your own peril
[22:16:01] nfk: good night, everyone
[22:16:07] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-02-03

[09:42:45] nfk: has joined #ruby
[11:33:20] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-02-02

[07:26:53] nfk: has joined #ruby
[09:02:30] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-01-30

[07:50:24] nfk: has joined #ruby
[10:26:18] nfk: Ping timeout: 245 seconds
[10:45:31] nfk: has joined #ruby
[12:40:11] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-01-29

[09:19:10] nfk: has joined #ruby
[12:44:40] nfk: Quit: Try memory.free_dirty_pages=true in about:config
[18:22:56] nfk: has joined #ruby
[22:57:22] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-01-23

[09:31:24] nfk: has joined #ruby
[12:03:55] nfk: Remote host closed the connection

2019-01-21

[19:25:42] nfk: has joined #ruby
[19:34:46] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-01-20

[15:48:46] nfk: has joined #ruby
[17:47:04] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-01-18

[01:14:27] nfk: Quit: Try memory.free_dirty_pages=true in about:config
[19:21:14] nfk: has joined #ruby
[20:10:08] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-01-17

[23:04:34] nfk: has joined #ruby

2019-01-15

[00:09:59] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-01-14

[23:29:49] nfk: has joined #ruby
[23:33:39] nfk: ModusPwnens, and the standard answer is that it's supposed to be intuitive to matz
[23:33:45] nfk: been there, asked that
[23:34:10] nfk: or rather, been here; asked that
[23:41:07] nfk: are there good orm's for a single file script to access a basic db - sqlite would be neat but i can probably live with something much simpler
[23:44:28] nfk: havenwood, neat, looking at the example, looks pretty much what I had in mind. thanks
[23:48:17] nfk: wait, a rescue on function? is that legit?

2019-01-05

[03:51:53] nfk: has joined #ruby
[03:52:31] nfk: Argh, just to be sure, if File.rename "foo", variable_that_is_undefined is called
[03:52:41] nfk: it successfully eats the data by renaming it to nil, yes/
[03:53:03] nfk: oh, wait, phew
[03:53:07] nfk: it's not undefined
[03:53:27] nfk: i may have clobbered something but the data might be still here
[04:02:51] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2019-01-01

[14:35:03] nfk: has joined #ruby
[14:43:03] nfk: Quit: Try memory.free_dirty_pages=true in about:config
[21:36:51] nfk: has joined #ruby
[22:29:51] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-12-23

[03:04:26] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-12-22

[18:13:48] nfk: has joined #ruby

2018-12-16

[01:07:48] nfk: Ping timeout: 246 seconds
[01:11:28] nfk: has joined #ruby
[01:30:00] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-12-15

[19:28:01] nfk: has joined #ruby

2018-12-11

[14:53:04] nfk: has joined #ruby
[19:31:12] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-12-04

[15:01:26] nfk: has joined #ruby
[15:37:15] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-11-21

[20:39:25] nfk: has joined #ruby
[23:30:34] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-11-20

[17:15:37] nfk: has joined #ruby
[21:19:35] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-11-19

[23:08:57] nfk: has joined #ruby
[23:55:04] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-11-06

[02:11:52] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-11-05

[20:09:36] nfk: has joined #ruby

2018-11-04

[00:12:07] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-11-03

[22:33:32] nfk: has joined #ruby

2018-11-01

[04:42:44] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-10-31

[01:57:10] nfk: Quit: Try memory.free_dirty_pages=true in about:config
[18:44:25] nfk: has joined #ruby

2018-10-30

[20:42:27] nfk: has joined #ruby

2018-09-19

[11:31:52] nfk: has joined #ruby
[11:34:12] nfk: i can't believe i spent like 4 hours yesterday debugging firefox csp, sinatra, rack-protection and my app when the cause was NoScript running in my firefox...
[12:00:47] nfk: donofrio, i obviously run noscript inside it as well
[12:01:46] nfk: after all, i do about half of my googling in private or incognito just so that algorithm didn't start spamming me with lawnmover or lisp framework results
[12:05:41] nfk: that's some code spaghetti you've got going there
[12:07:14] nfk: some easy things first: 1) it's good that you're using @percent to indicate that it's a percentage but if you're actually doing math on it, it's much safe to just keep it as a float and format it as a percentage only when shown in a human friendly manner
[12:09:03] nfk: that way if stuff goes sideways you'll end up with 0.2% discount where it should have been 20% instead of substacting 20, because someone forgot to do the conversion
[12:09:39] nfk: alireza, hey, you have to be careful with money, if you bill me €-5, i'll take them and the product, thank you
[12:13:17] nfk: alireza, it's just a good practice, when it comes to money, to avoid using percentage as your internal representation
[12:15:43] nfk: alireza, and i'm sharing my opinion on how i'd avoid some pitfals, speaking of which, i would have order.base_total and order.total
[12:16:09] nfk: that way, again, if stuff goes sideways, you won't end up repeatedly applying the same discount
[12:18:12] nfk: you'd likely also want to do all your discounts in one place (i.e. pass in order and some hash of all potentially applicable discounts)
[12:20:16] nfk: alireza, i think that if you redo your discounting to all happen in one place, then you won't have that issue in the first place but that's just me
[12:26:26] nfk: yeah, i see a lot of abstraction with very little code, which is why i called that code spaghetti
[12:27:13] nfk: alireza, my gut feeling without considering that spaghetti is that when you call super the self it's being called on is not what you think it is but that's just my first hunch
[13:44:31] nfk: BrainWork, well, if you're just fooling around, maybe try http://rubykoans.com/
[13:45:03] nfk: i remember having quite a bit of fun with those when i started, though it was some online interpreter rather than a set of local files
[13:46:22] nfk: BrainWork, this might be of interest to you: https://news.ycombinator.com/item?id=9308684
[13:46:59] nfk: ACTION goes on a run to do some errands
[17:25:41] nfk: those were some long errands but, hey, at least i got move a bit
[18:21:12] nfk: Oh, derp, I'm testing my webapp on both firefox and google chrome and i'm getting different colors!
[18:35:37] nfk: On one hand I feel like pursuing this rabbit but I know that color management is gonna be one hellish rabit hole. Especially on linux. After all, all my profiles (other than my mpv vo_gpu one) is set to a test profile with wacky colors - if anything was capable of picking them up, I'd immediately notice that
[18:36:07] nfk: s/is/are/
[20:25:30] nfk: and oz already linked you with pretty much the stuff everyone learns from (obviously from the ones that fit their taste)
[20:26:32] nfk: as for the ones you listed, i have no idea about their teaching style as i learned js the hard way - by writing application code before the days of node
[20:27:33] nfk: ecmascript as a language is so simple that i'm always baffled by people who need to learn it
[20:30:21] nfk: i find it pretty difficult to max out anything that large
[20:31:24] nfk: also i was under impression that 58 usable bits for memory addresses on 64 bit arches was an implementation approach rather than a language feature
[20:32:47] nfk: couldn't they actually have BigInt implemented in JS?
[20:44:24] nfk: actually, how would they end up losing money? it was a bit less than I thought - just mere 2.8e17 but that's seems to be enough to track the world's economy at a fraction of penny/cent precision
[21:08:02] nfk: don't feed the troll
[21:40:16] nfk: if you meant nil?, then... you might be able to not have one if you essentially uprooted or replaced the entire runtime
[21:40:26] nfk: but as things stand, yes
[21:45:16] nfk: Dirak, oh, i just realised i automatically removed the ? from .nil because you were asking a question, sorry
[21:56:49] nfk: my gut feeling is that it just might be to avoid a circular definition, because object_id has to return an object?
[22:00:04] nfk: is it even a bitwise operator in C++ is my first question
[22:00:10] nfk: anyway, ObjectSpace._id2ref 2
[22:00:12] nfk: try that
[22:03:01] nfk: Dirak, anyway, my bad, << is the bitwise operator, and it's also doing the same job in ruby: a = 1; puts a; a <<= 2; puts a
[22:03:39] nfk: what you might be confused about is the fact that it's just a method (just like in C++), which means that you can define your own /, + and, yes, <<
[23:34:37] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-09-18

[00:27:41] nfk: the code i'm writing looks so evil i'm glowing from the lovecraftian glee
[00:28:29] nfk: no, that will be for another time but it took two irb instances and hours to prototype
[00:29:04] nfk: this is one part of the prototype code: (h.method :fetch).call(:home).method(:merge!).call(test: {})
[00:29:24] nfk: and this is another: p.ascend.inject([]) { |a, e| p a << e.basename.to_s }.reverse
[00:29:46] nfk: i should feel bad about my actions, right?
[00:32:38] nfk: ACTION does the Burns gesture as they contemplate how to iterate on this wretched array
[01:52:20] nfk: https://paste.ubuntu.com/p/dcTrTMdkwK/ // behold, do i qualify for the cabal of the unspeakable one yet?!
[01:54:50] nfk: hohoho, it even works if set it to a directory deep in my filesystem hierarchy
[03:27:29] nfk: havenwood, wouldn't such an outdated version of ubuntu be long past security updates?
[04:01:29] nfk: on one hand it's cool they support stuff for 5 whole years. on the other hand software that old is dreadful
[04:02:09] nfk: the coolest thing you get to play there is the shorthand for defining hashes
[04:02:19] nfk: *with there
[04:03:53] nfk: speaking of dreadful software, i got to listing folders right below sysroot in sinatra, which i can't say about the tk GUI
[04:05:03] nfk: also long overdue good night, everyone
[04:07:14] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-09-17

[17:27:13] nfk: that having been said, true *nix programs that wait for closing of all open connections will regard any number of SIGINTs
[17:28:00] nfk: RedNifre, that's just from my memory as i have never written anything like that but i think you're supposed to handle SIGINT yourself if you do not want your runtime or something handling it for you
[17:28:45] nfk: probably something like it moving from your app to the runtime to language to stdlib to kernel? just a wild guess
[17:31:37] nfk: RedNifre, i think *nix signal handling conceptually is a lot like Exception handling - if you catch it, it's then up to you to handle the situation, possibly including not handling a repeated SIGINT if the user becomes impatient
[17:41:38] nfk: RedNifre, in that case, you should also use a certain pattern to ensure that the file does not get corrupted even on forced termination. i'm quite certain there's a certain Linux pattern you're supposed to use, i just can't seem to find it
[17:52:12] nfk: RedNifre, i could not find the pattern, so take this with a grain of salt but I'd do something like this: 1) periodically create a new file (rather than overwriting the old one), 2) wait for sync to finish on it, 3) mv the previous version of log to .old (i.e. foo.log.old), 4) mv the new version to be the main file and 5) rm the old version. Optionally you might do a filesystem sync after all of this. Do note that this is (probably) safe only on GNU/Linux!
[17:53:15] nfk: for obvious reasons this is a generic pattern that is not feasible with either very large files, a system serving a lot of I/O and probably few more cases even on GNU/Linux
[17:59:02] nfk: oh, and do note that it's not impossible for the mv foo.log foo.log.old; rm foo.log.old to happen before mv foo.log.new foo.log.old leaving you with the new but not the main log file!
[18:00:15] nfk: also you probably need to re-open the main log if you're also reading from it as on *nix it will likely be pointing to the old file that you deleted
[18:01:15] nfk: *happen before mv foo.log.new foo.log
[21:09:43] nfk: Inside, in my noob experience code is either way too slow or fast enough that you don't care about actual speed ;)
[21:14:47] nfk: after all, i literally have a CPU from 2008 if not earlier yet it's currently at sub 10% on average (with immediate per-core use often 0.0%) and both graphical and video cores, and even Gen 1 PCIe at 0% utilization even though I'm currently running a modern web browser, a compositing desktop and a capistrano webapp all while chatting on irc
[21:15:33] nfk: meanwhile a previous generation ultrabook with discrete graphis would run laps around this system
[21:24:42] nfk: ah, so that's why people don't like it
[21:52:35] nfk: 1) check that it's not nil: nil.nil? which will return true if it is nil. 2) check that element.respond_to? :method_name or 3) just try it and handle the NoMethodError exception if it's thrown at you OR 4) there might be a bug in your code due to changes and a class member that's not supposed to be nil is not being assigned its correct value
[21:52:49] nfk: there's actually more ways but they'll just be different variants of 1 and 2
[21:53:27] nfk: btw, it's said that the most ruby way is to just try and handle exceptions
[21:57:43] nfk: Inside, does that mean that you're trying to solve a non-existing issue?
[21:58:33] nfk: also the number of records is pretty low as far as databases go but i'm not sure if the same goes for set operations (not my field of expertise though)
[21:59:00] nfk: assuming by record you don't mean something like a whole document
[22:00:43] nfk: Inside, actually have you considered just doing it in sql?
[22:03:17] nfk: if synchronicity is not an issue how about just getting the data you need from the slow database into some temporary database and use that?
[22:04:54] nfk: ah, is that the slow one?
[22:05:09] nfk: oh wait, it's supposed to be very fast
[22:06:12] nfk: ACTION feels a bit lost on what exactly Inside is trying to accomplish by optimizing an alleged non-bottleneck
[22:16:43] nfk: we'll see
[22:17:07] nfk: i'm currently feeling scared as my irb just got 33000 entry hash
[22:17:15] nfk: that was.. a sight
[22:17:27] nfk: can i do 67k?
[22:17:56] nfk: to get to 100k hash
[22:18:12] nfk: so far my RAM seems to be completely in check which was the scary part
[22:19:00] nfk: first one down, time for the second one
[22:19:24] nfk: actually, my keys looks pathetic
[22:19:50] nfk: oops.... i feel stupid
[22:21:14] nfk: ho, ho, i can hear the cpu fan spinning up
[22:22:18] nfk: yeah, this time my ram is actually growing
[22:24:55] nfk: Inside, sorry, i don't think i'll be able to try what you're doing even with a simple hash as i'm nearing swapout point yet i'm less than 2/3 into the first hash generation
[22:25:31] nfk: had to abort XD
[22:25:50] nfk: have you tried it on your end?
[22:27:06] nfk: h = {}; 100000.times.map {|n| h.merge!({Random.rand(1000000) => n})}
[22:28:00] nfk: this should generate a hash with 100k elements. unfortunately i suspect your values will be more than simple integers but at least that should give you a feel for what you'll be up against
[22:29:28] nfk: did i get something wrong?
[22:30:29] nfk: do go on
[23:08:52] nfk: this is some sick capability: (Pathname.new("/home/user/test 1") / "../test 2/../test 3").cleanpath
[23:15:57] nfk: isn't the whole point of JSON to have a data format that can be parsed without validating it?
[23:16:59] nfk: i'm very certain he meant field presence, data types and possibly absence
[23:17:51] nfk: so basically that the client response more or less fits the bill, at which point the whole point of having a ubiquitous format that can be flexible in it's format and content is out the window, imho
[23:20:22] nfk: baweaver, also sorry that only now i noticed your use of singular "them". let me tip my virtual hat to you
[23:20:38] nfk: it seems i'm really getting tired
[23:21:41] nfk: baweaver, validating format and validating schema compliance are two different things
[23:22:03] nfk: i doubt invalid JSON would parse without an exception
[23:22:47] nfk: i'd love to give examples but i really should get back to my app before i get any more tired
[23:25:10] nfk: baweaver, is this the next version of: "validating e-mail addresses: how hard can that be? TM"?
[23:25:40] nfk: would be funnier if 90% of university professors didn't think it was easy
[23:31:27] nfk: i mean it in general: with the exception of my compsec professor (who was a literal professor and board member) no one seemed to have even a hunch that e-mail address validation is one deep rabbit hole
[23:45:19] nfk: baweaver, so i ended up reading good portion of that website. thanks for the link, that was quite interesting. also nowhere near as bad as e-mail validation from what i recall
[23:46:59] nfk: oh, they're fun to just write. forget parsing :D
[23:48:00] nfk: nothing quite like writing in a programming language few know well and one that very different from your run of the mill languages
[23:48:07] nfk: what could possibly go wrong with that, right? TM
[23:48:16] nfk: *that's
[23:50:15] nfk: i head the expert advise of leaving C to the handful of professionals that can be trusted with not making horrific mistakes and cross my fingers that linux kernel is safe enough