nfk

Activity Graph

Page 1 of 11 | Next »

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

[14:44:20] nfk: has joined #ruby
[14:47:50] nfk: hello, sorry for my google skills failing me on this silly question but how do i get and process output of a block? i'm iterating over a Dir.glob with a block and the final value of each iteration is already what I want but I can't figure out how to collect them in an array or even just a string without using something ugly like passing a variable into the block, which I could to but i'm certain there's a more beautiful ruby way to do it
[14:53:32] nfk: apeiros, yeah, i literally just wrote that into my code
[14:53:35] nfk: testing it now
[14:54:16] nfk: i feel a bit silly now but it proves that it's all about asking the right question. btw just out of curiosity can i collect the final value of each iteration in ruby?
[14:56:35] nfk: yeah, i just printed what i wanted: ["usr", "boot", "bin", "dev", "etc", "home", "lib", "lib64", "media", "mnt", "newroot", "opt", "proc", "root", "run", "sbin", "srv", "sys", "tmp", "var", "fio"]
[14:56:43] nfk: needs more work, naturally but at least i'm getting there
[14:56:59] nfk: now.. if only ruby had a decent gui and i didn't have to write on in capistrano :D
[15:00:31] nfk: apeiros, btw, is it better on humane grounds to assign a Dir.glob array to a variable and then map { ... }.sort! that or to just go Dir.glob ... .sort in one swell swoop?
[15:01:37] nfk: i'm inclined towards the later but i can't recall anyone ever having done that so i'm a bit worried about the sanity of anyone who might read my code
[15:02:19] nfk: apeiros, come again on that, please? I'm not sure i groked that
[15:03:14] nfk: huh, would that be like [1, 2, 3].map! {|n| n*n } => [nil, 4, 9]?
[15:03:55] nfk: that boggles my mind
[15:05:12] nfk: why would 1 be returned when 1 and the return value of 1*1 should be the same object just like "HI" and "HI".upcase! ?
[15:08:11] nfk: so map! is safe but sort!, upcase! and most others are not?
[15:09:54] nfk: yeah, thanks both for your initial answer and this explanation. i have a weird feeling that i might have hit that landmine before but never figured out what was going on and just not used map altogether
[15:10:02] nfk: oh wait, not map but..
[15:11:02] nfk: hmm.. i can remember the Rails project which gave me the most headaches but can't recall which method i got to work around as it was just giving me missing values
[15:37:00] nfk: i think the first question here should be what is a scope
[15:37:42] nfk: e.g. would a piece of code such as this: foo = "bar" introduce a variable that does not exist beyond certain bounds be considered a scope?
[15:38:04] nfk: let me regrammarise that
[15:38:35] nfk: e.g. would a piece of code such as this: foo = "bar" introducing a variable that does not exist beyond certain bounds be considered to define those bounds as a scope?
[15:39:06] nfk: havenwood, no, that's the first question because i suspect that ruby has at least two answers to his original question depending on how one defines a scope
[15:39:29] nfk: that having been said, i personally do not care about such things so it's just a hunch i have after years of rubying sometimes
[15:40:29] nfk: phaul, i'm just a noob, sorry. but my first one would be what i just asked. the second one is probably along the lines of either language design intent and lexical/syntactical distinctions but i do not know how to define it more clearly
[15:42:59] nfk: phaul, but if you want an answer from a noob, then i'd say that stackoverflow guy with 5 is closer to a practical definition of a scope even if the linguistically correct answer is a smaller number. Also I suspect the "expert" intentionally avoided the top level (script?) scope as it's not an intentional scope but a requirement to make the language work (i think)
[15:44:22] nfk: havenwood, how about instead of answering a question with a question you gave us your honest opinion to the question of "how many scopes does ruby have?"
[15:48:29] nfk: havenwood, look, i might be a ruby noob but i do have a degree in software engineering. a scope is a perfectly valid if a bit practically-conceptual term that denotes contexts within programming language where defining or redefining things do not clobber things of the same name and type in another scope
[15:52:28] nfk: havenwood, which is why after years of rubying i still can't answer this basic question ;) i kinda get what you're saying and that's also exactly what i feel about the definition of bodyparts but i still prefer to have a loose yet practical definition over saying: "Reality is too dificult to describe exactly so let's either give up or use some totally abstract yet mathematically valid notation"
[15:55:09] nfk: havenwood, i know, just like a vegetable is completely arbitrary definition for roots and fruits and whatnot, so does that mean we should forget about the the word "vegetable" or answer: "how many fingers does a human arm have?" with: "there are no arms because they're too dificult to define"
[15:56:35] nfk: wasn't ruby supposed to not surprise people familiar with it?
[15:59:17] nfk: except i want to think like myself
[16:00:19] nfk: it has a lot more to do with it not having a connection to the academia
[16:03:05] nfk: phaul, so in short, there's >=5 scopes in ruby; whether to go down the rabbithole or do something else is up to you
[16:03:24] nfk: also "expert" is anyone who has written a book, write one yourself
[16:05:02] nfk: ACTION wonders if that might have been a shameless plug
[16:09:30] nfk: in more practical news, as you can always work around getting and setting, they're a bit useless
[16:12:07] nfk: the theoretical point of them is that you have methods through which you interact with some hidden internals of a class as if it was a member variable but in reality this tends to be just a bunch of boilerplate for a variable that's essentially impossible to keep away from outside tampering
[16:13:17] nfk: NL3limin4t0r, yeah, i avoided saying that for brevity and the fact that people who need to know this already would know it so i didn't say that ;)
[16:14:37] nfk: NL3limin4t0r, also observe that i never said there even was an internal variable just that if one has access to them they are next to impossible to keep away from whatever internals there are
[16:14:56] nfk: them being the getter and setter
[16:33:31] nfk: havenwood, first, i doubt it will be very effective. You would need actual anti-tampering code and even then i'm not sure how effective that would be considering that people, i imagine, produce cracks for even obfuscated proprietary software without any source code publicly available. And this is not a ruby specific issue, getters and setters being misunderstood (along the entire OOP visibility fluff) as a security feature is a common part of OOP (mis)
[16:33:33] nfk: understanding and teaching
[16:40:28] nfk: rgr, this is actually more about systems administration. I think it boils down to the way you interact with your ruby app. What I'd do in your place was to either try installing ruby elsewhere that would be system-wide (/usr/local comes to mind) or use the system provided ruby OR I would run a ruby application server that was only accessible locally (or from a (V)LAN, which is neat for scaling) and then have the forward facing http server send requests it does
[16:40:30] nfk: not know to the application server over either local socket or loopback interface
[16:40:59] nfk: NL3limin4t0r, again, my criticism is true for every single OOP implementation that I have ever learned
[16:42:46] nfk: furthermore i criticized the way people misunderstand due to misinformation and bad instructors what is a language abstraction feature as a security feature; finally at most i implicitly criticized languages for allowing to bypass this level of abstraction, essentially defeating it's purpose
[16:55:00] nfk: s/as/for/
[16:55:26] nfk: s/it\'s/its/
[17:02:39] nfk: NL3limin4t0r, solder? i can chisel that easily. Maybe you meant weld? That would make it harder for themselves, also at least in EU that would be illegal if one couldn't replace bulbs or air filters easily
[17:05:50] nfk: havenwood, NL3limin4t0r, again, i'm not singling out ruby for this, so chillax; all OOP implementations that I know are the same in this regard. And I never said they should disallow it for security reasons as those would be relatively easy to circumvent anyway but rather they should enforce it for the sake of staying true to OOP, if the programmer has apparently explicitly decided to embrace the use of getters and setters
[17:06:49] nfk: havenwood, i think you still have ways to go, bob (marley)
[17:11:02] nfk: havenwood, then why have OOP anyway? the whole point is to force a certain external API for your code, which is then undermined by the fact that anyone can just poke at the implementation internals anyway with the only meaningful difference being that you can change them and then smugly dismiss any bugreports or complaints as well deserved grievances for abusing your code - i'm sure some *cough* Red Hat *cough* people will get off from that
[17:15:48] nfk: NL3limin4t0r, this won't help you in any way but if A was a class you could extend it which is the correct way to do it, imvho; alas modules should not be extendible which is what you get for using a very old cold segmentation/sharing approach from like the 60's (or thenabout)
[17:16:38] nfk: sorry about that typo, that was just my subconsciousness telling me i should do something about the low temperature in my room
[17:18:16] nfk: RedNifre, from the top of my memory from a decade ago, it's finish up or something along those lines
[17:19:06] nfk: on *nix a program *MUST* disregard Ctrl+C if it's waiting on an open connection, iirc
[17:19:39] nfk: which is why NFS shares were so ungodly difficult to unmount in the olden days. and sshfs are today
[17:19:56] nfk: i would not be surprised if on windows this is not the case
[17:21:16] nfk: this is my first time seeing that, no idea
[17:22:00] nfk: RedNifre, actually, if your script handles stdio, then the normal unix way would be either q or Ctrl+D
[17:23:11] nfk: q being for programs that do not need to directly process stdio as part of their core operation while Ctrl+D would be for true *nix programs as a sort of in-band control by design (they are supposed to process a single file on stdio and then quit)
[17:24:48] nfk: RedNifre, then the next standard approach is using a signal and SIGINT seems reasonable as USRn are generally specific to the application and probably for operational rather than terminal signaling
[17:25:36] nfk: RedNifre, assuming you're correctly trapping SIGINT, then it must be either cygwin or windows specific, sorry
[17:26:44] nfk: from what i have seen, on *nix the first SIGINT is left to the app and the second either has some higher up handler that's very ubiquitous or is provided by the platform itself
[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

2018-09-16

[02:05:49] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-09-15

[01:53:21] nfk: Quit: Try memory.free_dirty_pages=true in about:config
[21:14:47] nfk: has joined #ruby

2018-09-14

[17:34:13] nfk: has joined #ruby
[17:37:01] nfk: tk's virtual event handling is driving me up the wall with the absolute lack of ruby specific documentation and none of tcl or python results i can google being of much use
[17:38:04] nfk: i got to the point of being able to call the handler (which is a bit ugly but whatever) but then the program gets a TypeError of all things...
[17:59:23] nfk: is it just me or virtual event in ruby/tk handling is not working as it's supposed to?
[18:00:03] nfk: *virtual event handling
[18:51:50] nfk: i would very much like to hear from someone who knows ruby/tk on how to get virtual event handling working

2018-09-10

[00:13:51] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-09-09

[21:47:57] nfk: has joined #ruby

2018-09-06

[01:52:40] nfk: Quit: Try memory.free_dirty_pages=true in about:config
[10:59:47] nfk: has joined #ruby
[12:36:25] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-09-05

[10:41:50] nfk: has joined #ruby
[13:09:00] nfk: Quit: Try memory.free_dirty_pages=true in about:config
[16:14:00] nfk: has joined #ruby

2018-08-21

[01:28:28] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-08-20

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

2018-08-13

[22:06:11] nfk: has joined #ruby
[23:40:02] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-08-03

[10:36:19] nfk: has joined #ruby
[13:05:55] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-07-16

[18:24:29] nfk: has joined #ruby
[18:26:09] nfk: Remote host closed the connection

2018-07-11

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

2018-06-12

[00:58:16] nfk: Quit: Try memory.free_dirty_pages=true in about:config
[17:00:57] nfk: has joined #ruby
[17:30:44] nfk: Remote host closed the connection
[17:38:14] nfk: has joined #ruby
[21:36:04] nfk: Remote host closed the connection
[22:01:04] nfk: has joined #ruby
[22:48:09] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-06-11

[10:07:19] nfk: has joined #ruby
[13:53:16] nfk: Quit: Try memory.free_dirty_pages=true in about:config
[17:39:14] nfk: has joined #ruby

2018-06-10

[19:42:24] nfk: has joined #ruby
[21:09:27] nfk: Ping timeout: 240 seconds
[21:34:05] nfk: has joined #ruby
[23:14:37] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-06-05

[13:09:48] nfk: has joined #ruby
[14:38:03] nfk: Remote host closed the connection

2018-06-04

[09:04:11] nfk: has joined #ruby

2018-05-31

[10:25:20] nfk: has joined #ruby
[11:12:05] nfk: Quit: Try memory.free_dirty_pages=true in about:config

2018-04-10

[15:22:47] nfk: has joined #ruby
[21:53:27] nfk: Ping timeout: 240 seconds
[21:57:01] nfk: has joined #ruby
[22:06:16] nfk: Quit: Try memory.free_dirty_pages=true in about:config