| programmerjake | oh, lkcl, reading through your modifications to bitmanip, crbinlog imho should take the look-up table from a GPR rather than a CR. this will make it much easier to generate. | 00:41 |
|---|---|---|
| programmerjake | much easier to use in user code because CR's are generally conditions rather than arbitrary binary values. | 00:41 |
| programmerjake | <ghostmansd[m]> "...as well as the fact that it's..." <- being written in rust doesn't automatically mean you're software is good...it just makes it waay easier to write good software. (I'm assuming you already know that though...) | 03:51 |
| ghostmansd[m] | programmerjake, I believe good software can be written in any language. The truth is, bad software can be written in any language as well. :-) | 06:22 |
| ghostmansd[m] | After all, it's programmer who writes the software, the language is just a tool. Some tools are better for this task, others better for that, and so on. | 06:24 |
| ghostmansd[m] | I don't buy arguments like "with Rust it's simpler to write good software", because, at least, the argument is not complete. Which software _exactly_? | 06:25 |
| ghostmansd[m] | For example, one might say: with Python, it's simpler to write prototypes. With Go, it's simpler to write web servers. With C, it's simple to write OSes (at least because any other sane OS is written in C, so you at least can look at it). And so on. | 06:30 |
| programmerjake | i didn't say simpler, i said easier. that's because I think good typing and tests and no UB are a big part of what makes good software and rust excels at those | 06:42 |
| programmerjake | rust can be more complex, but that extra complexity are the parts that let you guarantee your program will function correctly because it could compile -- aka. the compiler is checking a large fraction of what you need for your program to be correct | 06:44 |
| programmerjake | e.g. rust promotes the idea to use types so that incorrect states can't occur since the types used guarantee that you can only transition to valid states | 06:45 |
| programmerjake | rust isn't easier to write software, it's easier to write *good* software imho | 06:47 |
| programmerjake | ghostmansd[m] ^ | 06:47 |
| ghostmansd[m] | Ok, easier. Doesn't matter that much. | 06:50 |
| ghostmansd[m] | I don't get why you blame UB. This is one of trade-offs, and C chose UB not without the reason. | 06:51 |
| ghostmansd[m] | You can have C without UB, by the way, and there an effort to do it. But, in the end, it seems nobody cared that much. | 06:53 |
| programmerjake | because C and C++ you always have to be careful to not accidentally cause UB, which is pretty easy to accidentally do even if you're paying attention and are an expert C programmer. Rust makes it impossible to cause UB unless you use the `unsafe` keyword, greatly limiting the parts of your program that needs extra scrutiny unlike C where that's basically the whole program | 06:54 |
| ghostmansd[m] | As for type checking and ownership, this is just syntactic sugar. Yes, it's helpful. Praising the language for it? I don't think it deserves. | 06:54 |
| ghostmansd[m] | Again, UB is a trade-off, and, to the major extent, legacy atavism. | 06:55 |
| programmerjake | it's more than just type checking, it's also the abstractions built on those types. e.g. Rust traits are waay more powerful than most other programming languages' type systems | 06:56 |
| ghostmansd[m] | Does Rust need to support non-2-complement systems? | 06:56 |
| ghostmansd[m] | C is intended to support every piece of junk you have in computer museums. | 06:57 |
| ghostmansd[m] | This is yet another source of quirks and UB. | 06:58 |
| ghostmansd[m] | Again, wordings like "powerful" or "easier" or "you don't have to be as careful as in C" are not gonna buy me. :-) | 06:59 |
| programmerjake | no, but that isn't where rust derives its power...a version of rust with support for ones complement or sign-magnitude computers would still be waay better than C in terms of UB....overflow is deterministic, unlike C where compilers treat overflow as permission to format your harddrive (or other serious problems) | 07:00 |
| ghostmansd[m] | Which are good and well-known projects in Rust, except for Servo and the Rust itself? | 07:02 |
| programmerjake | firefox? | 07:02 |
| programmerjake | wasmtime | 07:03 |
| programmerjake | cranelift | 07:03 |
| ghostmansd[m] | I wouldn't call Firefox a good code base. | 07:03 |
| programmerjake | they're making it better by adding rust... | 07:03 |
| ghostmansd[m] | Two others I haven't even heard of about. | 07:03 |
| ghostmansd[m] | Oh, for God's sake. :-) | 07:04 |
| ghostmansd[m] | Nah, not interested... :-) | 07:04 |
| programmerjake | cranelift is a fast jit compiler....wasmtime is a web assembly vm | 07:04 |
| programmerjake | linux kernel? | 07:04 |
| ghostmansd[m] | Oh well, so, since recently they introduced Rust to kernel only for device driver, you now consider it a proof that Rust is great? | 07:05 |
| ghostmansd[m] | So, some lunatics pushed for it, Torvalds agreed, end of the story. Proves nothing at all. | 07:06 |
| ghostmansd[m] | Any real used OS written in Rust? | 07:06 |
| programmerjake | i'm looking for a list... | 07:06 |
| ghostmansd[m] | Not for educational purposes. | 07:06 |
| ghostmansd[m] | Not for fun. | 07:06 |
| ghostmansd[m] | Real, ready-to-use and _used_ OS. | 07:06 |
| ghostmansd[m] | I can tell you that go is a great language, because, hey, "they wrote docker in it". | 07:07 |
| ghostmansd[m] | Does it prove that go is great? No fricking way. | 07:07 |
| ghostmansd[m] | I can say, "hey, but go has channels, and goroutines, start using go everywhere!". Would you listen to me? | 07:08 |
| programmerjake | there aren't currently any major oses in rust mostly because rust is new and everyone just uses what already works | 07:08 |
| programmerjake | go doesn't have decent generics last i checked, also it has a gc | 07:09 |
| ghostmansd[m] | C'mon, it doesn't take that much time to write a kernel. Rust could have occupied at least some niche, e.g. offer some basic RTOS. For example, substitute BUGURTOS. | 07:10 |
| ghostmansd[m] | I'd say that there's a proposal on generics and would also say that gc is great, because you don't have to worry about memory! | 07:11 |
| ghostmansd[m] | (obviously I'm sarcastic) | 07:11 |
| ghostmansd[m] | I mean, anything can be an argument, when we're speaking of religion, eh? | 07:11 |
| ghostmansd[m] | This debate is not a technical, but, rather, religious. | 07:12 |
| programmerjake | well, in a benchmark i saw a while ago, the fastest webserver they tested was written in rust | 07:13 |
| programmerjake | actix iirc | 07:13 |
| ghostmansd[m] | Does anyone use this amazingly fast webserver? | 07:13 |
| ghostmansd[m] | But hey, I'm OK with Rust, as with most languages, I just don't like that some corporations and individuals offer it so aggressively. | 07:14 |
| ghostmansd[m] | And, again, as long as it's suitable for a task, it's OK. I have yet to see, though, where Rust really fits better than C. | 07:14 |
| ghostmansd[m] | Maybe device drivers. | 07:15 |
| ghostmansd[m] | Especially dealing with 3rd-party data, perhaps. | 07:15 |
| ghostmansd[m] | Though, frankly, I'd rather see RPC there. | 07:15 |
| ghostmansd[m] | With automatic code generation. | 07:15 |
| programmerjake | list of remarkable users of actix: https://github.com/actix/examples | 07:15 |
| ghostmansd[m] | ...major part of projects unsurprisingly uses Rust. | 07:18 |
| ghostmansd[m] | That's kinda lion licking himself meme, you know? | 07:18 |
| ghostmansd[m] | But, again, I'm off this discussion, because I already participated in it a lot, and arguments are all the same, and the whole hideous cycle will just go on and on and on. | 07:20 |
| ghostmansd[m] | https://youtu.be/zKIjVwiabSU | 07:21 |
| programmerjake | well, not that it's very widespread yet, but crev (a system for reviewing code in software releases but with distributed cryptographic properties similar to pgp) is written in rust | 07:23 |
| programmerjake | https://github.com/crev-dev/crev/ | 07:23 |
| programmerjake | oh, apparently bytedance (of tiktok fame) uses rust for their cross-platform client-side software | 07:34 |
| programmerjake | you were asking about rust operating systems, iirc the biggest one is redox-os which is not very widely used yet | 07:42 |
| programmerjake | oh, also the solana blockchain is written in rust | 07:51 |
| programmerjake | iirc that showed up on the news a bit (cuz some people use it to make NFTs) | 07:52 |
| programmerjake | kinda related news: the linux foundation and openssf are coming up with a plan to replace c and c++ with memory safe languages like rust or go: https://openssf.org/oss-security-mobilization-plan/ | 08:21 |
| programmerjake | (to be clear that's their words, imho go isn't memory safe) | 08:23 |
| ghostmansd[m] | Well, redox-os is exactly why I asked you to bring an example of something which is used. | 09:20 |
| ghostmansd[m] | Not just, you know, something written in Rust to show you _can_ write it in Rust. | 09:21 |
| programmerjake | well, that's kinda hard, because I could point to a long list of software written in rust and you could just say they wrote it in rust because they wanted to...which is true but also kinda pointless because we could do the exact same thing for nearly any other mainstream language | 09:23 |
| programmerjake | e.g. nmigen is written in python because they wanted to | 09:24 |
| programmerjake | oh, also solana is actually quite popular iirc | 09:25 |
| ghostmansd[m] | I've not used Solana, but I heard that Rust is language of choice for blockchains. | 09:26 |
| ghostmansd[m] | At least, perhaps, this will become Rust niché. | 09:27 |
| programmerjake | maybe, but imho it's far from the only niche | 09:28 |
| ghostmansd[m] | I'm speaking of successful ones. ;-) | 09:28 |
| programmerjake | random google result about solana: https://blockworks.co/solana-volume-soars/ | 09:28 |
| programmerjake | imho rust is pretty successful in the write-it-in-webassembly space, though i don't have any stats rn | 09:29 |
| programmerjake | https://marketresearchtelecast.com/state-of-webassembly-2021-the-most-popular-language-for-wasm-applications-is-rust/83312/ | 09:31 |
| ghostmansd[m] | Ok, let's hope there will be space for any good language, Rust included. | 09:37 |
| programmerjake | :) | 09:38 |
| ghostmansd | lkcl, programmerjake, did you reach consensus on grev* insns? | 10:07 |
| ghostmansd | Or should I submit binutils patch w/o these? | 10:08 |
| programmerjake | wip, he hasn't yet responded to my latest proposal for different semantics... | 10:08 |
| ghostmansd | I see there are updates on fields.text | 10:08 |
| lkcl | the mozilla foundation is *not* a good example in any way. they are a pathological organisation with top-down one-way push of dictats from management. | 10:09 |
| ghostmansd | But no declarations of these in chat, so I'm assuming this is a draft. | 10:09 |
| lkcl | people with serious amounts of experience in security vulnerability research and strategy have been systematically ignored for decades | 10:09 |
| programmerjake | imho just submit the patch without ternlogi or grev*, lkcl what do you think? | 10:09 |
| ghostmansd | ternlogi is also out of scope? | 10:09 |
| ghostmansd | I thought this one was OK | 10:10 |
| programmerjake | hmmm... | 10:10 |
| ghostmansd | There's even encoding/decoding test already :-D | 10:10 |
| programmerjake | guess you could include ternlogi but not the other binlog/ternlog instructions... | 10:10 |
| lkcl | ghostmansd, don't submit *any* patches to binutils until the OPF Board comes back with a decision, but do prepare them | 10:10 |
| ghostmansd | Ah, so we'll be just keeping these in fork for a while? | 10:11 |
| ghostmansd | I thought it'd be a great idea to let Alan look at these, but I get your point | 10:11 |
| programmerjake | ahh, yeah, I forgot about the non-technical side of submitting patches | 10:11 |
| lkcl | indefinitely, yes - unless they say it's ok to do them via an external dynamic-loadable-module (dlopen/dlsym) | 10:12 |
| ghostmansd | Ah, OK | 10:12 |
| lkcl | programmerjake, you remember the equivalent discussion on RISC-V? | 10:12 |
| programmerjake | not on binutils but i saw a little of that in llvm | 10:13 |
| programmerjake | they just used an --experimental flag in llvm | 10:13 |
| ghostmansd | We use -mfuture. | 10:13 |
| lkcl | several of us - all working externally - had a very large discussion 2+ years ago on how at the *ISA* level to avoid the nightmare conflict situation when several high-profile implementations contend for an *officially-sanctioned* "custom" opcode space | 10:14 |
| programmerjake | iirc that may be the clang flag rather than llvm proper | 10:14 |
| lkcl | the problem-words: "high-profile public" mixed with "same custom opcode space" | 10:14 |
| programmerjake | i'm starting to recall binutils wouldn't accept any non-standard instructions upstream for riscv | 10:15 |
| lkcl | high-profile usage of CUSTOM_OP1 e.g. by the alibaba group | 10:15 |
| lkcl | programmerjake, ohh no, they've already made the decision to accept them, from not just one but *multiple* sources | 10:15 |
| programmerjake | yeah, my info on riscv binutils is several years out of date | 10:16 |
| lkcl | sifive and the alibaba group's custom instructions are *both* going through patches to binutils *right now* | 10:16 |
| lkcl | with a 3rd company having patches that they're submitting as well | 10:16 |
| lkcl | this is all for the exact same custom opcode space! | 10:17 |
| programmerjake | since we switched to openpower i care about riscv a whole lot less so didn't pay attention | 10:17 |
| lkcl | the reason i'm paying attention is to demonstrate the shit-show that occurs (predicted 2+ years ago) | 10:17 |
| lkcl | so that it *doesn't* happen with OPF. i have hope / indicators that they're experienced enough to pay attention | 10:18 |
| ghostmansd | "sifive and the alibaba group's custom instructions are *both* going through patches to binutils *right now*" what a nice ISA to work with, eh? | 10:19 |
| lkcl | the general rule for Power ISA for 25 years has been "no conflicts allowed, at all". they went through one version of hell on that already, with altivec | 10:19 |
| ghostmansd | or, rather, a nice management | 10:19 |
| lkcl | ghostmansd, it's the people behind it who are extremely vicious and spiteful | 10:19 |
| lkcl | they tolerate abusive individuals | 10:20 |
| lkcl | it's a completely unsafe environment to work in, and it's already had consequences for RISC-V | 10:21 |
| lkcl | anyway, worth monitoring so as not to make the same mistakes | 10:22 |
| ghostmansd | OK, still, I'd like to have some summary | 10:23 |
| ghostmansd | I really want to understand the next steps on 834. | 10:23 |
| ghostmansd | 1. fsins/fcoss are ready (impl/tests). | 10:23 |
| ghostmansd | 2. ternlogi is ready as well (impl/tests), though programmerjake expressed some concerns. | 10:23 |
| ghostmansd | 3. grev* are ready as impl for current opcode mapping, but there's no agreement on grev* fate. | 10:23 |
| ghostmansd | It's all available in ppc-draft branch of our binutils fork. | 10:24 |
| ghostmansd | And, frankly, the uncertainty of the whole task makes all efforts useless, and I cannot even understand whether I should submit RFP. Work is complete partially, but I'm blocked. | 10:25 |
| ghostmansd | That is, official patch to binutils waits for OPF ack, and even the contents of the patch are uncertain, considering grev* insns. | 10:26 |
| ghostmansd | And, as such, SVP64 patch is blocked too. | 10:26 |
| programmerjake | my concern with ternlogi is that it isn't part of svp64 so should probably be a separate patch. other ternlog instructions aren't ready yet imho. | 10:29 |
| lkcl | ghostmansd, you've got the patches ready, i'd consider it complete | 10:30 |
| programmerjake | other than that, ternlogi is ready to go. | 10:30 |
| lkcl | you're "done" | 10:30 |
| lkcl | your part is done | 10:30 |
| ghostmansd[m] | But the tests for grev* cannot be done. Or can? | 10:31 |
| lkcl | can i suggest subdividing 550 with another task (considered "completed"): the writing of the sv_binutils.py autogenerator | 10:31 |
| programmerjake | currently testing grev is pointless since it'll most likely change | 10:32 |
| lkcl | no not yet. but *still* consider 834 done, and create *another* bugreport to track grev* (move grev* out of 834 in other words) | 10:32 |
| ghostmansd[m] | Ah, Ok | 10:32 |
| ghostmansd[m] | As for autogeneration... That's was 833 | 10:32 |
| ghostmansd[m] | And I already have RFP submitted, as we discussed | 10:32 |
| ghostmansd[m] | I don't know though how to edit it properly | 10:32 |
| programmerjake | for the rfp i just sent it to luke first for review, you don't have to do that tho | 10:33 |
| ghostmansd[m] | No, I mean, I should edit the task, right? | 10:35 |
| ghostmansd[m] | After I send RFP | 10:35 |
| ghostmansd[m] | lkcl, could you handle editing 833, please, to reflect that I already sent an RFP? | 10:35 |
| ghostmansd[m] | (but not yet received the payment) | 10:36 |
| ghostmansd[m] | And I'll submit RFP for 834 then as well. | 10:36 |
| programmerjake | ah, yeah. the field is in toml format, change it to `ghostmansd={amount=...,submitted=2022-05-17}` with the correct date and amount substituted | 10:37 |
| lkcl | ghostmansd[m], ah brilliant. | 10:38 |
| lkcl | ghostmansd[m], what programmerjake said. you can look at other bugreports to see how that goes | 10:38 |
| ghostmansd[m] | Ah, OK, perfect! | 10:38 |
| ghostmansd[m] | When the payment is received, should I update the task again? | 10:39 |
| lkcl | ghostmansd[m], yes, because otherwise budget-sync will still report it as "unpaid" | 10:39 |
| programmerjake | an example: https://bugs.libre-soc.org/show_activity.cgi?id=469 | 10:40 |
| lkcl | ghostmansd[m], please remember to add 15% of each task budget allocated to me. increase by 15% if necessary. | 10:40 |
| ghostmansd[m] | For 834 I'll have to increase, since I already submitted an RFP. | 10:41 |
| ghostmansd[m] | Hm, and it was not mentioned that it's split. | 10:43 |
| lkcl | ghostmansd[m], if you already submitted an RFP and it said "total is X" then *under no circumstances* change the amount | 10:44 |
| ghostmansd[m] | Would it be OK if 15% from 833 go to 834? | 10:44 |
| lkcl | hang on hang on, you're jumping the gun massively | 10:45 |
| lkcl | there's no records in the TOML fields and you've submitted RFPs but not sent them to me for approval | 10:45 |
| lkcl | so i now have no idea what the hell's going on | 10:45 |
| lkcl | the process is as follows: | 10:45 |
| lkcl | 1) set the budget | 10:45 |
| lkcl | 2) put the allocations into the TOML field | 10:46 |
| lkcl | 3) discuss and get approval from me | 10:46 |
| lkcl | 4) submit an RFP | 10:46 |
| lkcl | 5) notify me that the RFP has been sent | 10:46 |
| programmerjake | lkcl, does allocating 1000 eur to the smtlib2 bug for now sound good? having something there will make it harder to lose track of cuz of showing up in budget sync | 10:46 |
| lkcl | 6) update the TOML field to state "submitted={date}" | 10:46 |
| ghostmansd[m] | Ah, OK, sorry. I had an impression that fields in TOML are filled after the payment received. | 10:47 |
| lkcl | 7) update the TOML field with "paid={date}" | 10:47 |
| ghostmansd[m] | Sorry if it caused an inconvenience. | 10:47 |
| lkcl | no absolutely not, they're critical tracking information of the ongoing status | 10:47 |
| ghostmansd[m] | Is there documentation on process other than above? | 10:47 |
| lkcl | there are now over *eight hundred* bugs with hundreds of payments | 10:47 |
| ghostmansd[m] | (I can summarize it and publish somewhere) | 10:47 |
| lkcl | yes please, put it on HDL_workflow | 10:47 |
| lkcl | programmerjake, yes great idea | 10:48 |
| programmerjake | k | 10:48 |
| lkcl | ghostmansd[m], so even right now, i'm looking at the TOML fields for 834 and 833 and i'm going "ah, there's been no RFP submitted for either of these, and nobody's expecting to get paid" | 10:49 |
| lkcl | this is Accounting Procedures, which could get audited. it is *ABSOLUTELY* critically important that they're both correct and always, always up-to-date | 10:49 |
| ghostmansd[m] | Yes, I'm updating it | 10:50 |
| lkcl | thx | 10:53 |
| programmerjake | well, it's 3am here, gn all. lkcl, have fun with all the pretty diagrams i made! https://libre-soc.org/openpower/sv/bitmanip/grev_gorc_design/ | 10:53 |
| lkcl | programmerjake, :) | 10:54 |
| lkcl | i did say don't bother, but it helps compared to grevlut which is 512 instructions vs 2. | 10:55 |
| programmerjake | well....read my messages...it's waay more than 2 instructions worth | 10:55 |
| programmerjake | on the bug | 10:56 |
| lkcl | ok willdo. i'm a little behind | 10:56 |
| programmerjake | np, figured that was the case | 10:56 |
| lkcl | if by putting in 0x55555 or 0xaaaaa it can create the magic constants needed for emulating PMOVMASK[BHW] i'm good | 10:58 |
| lkcl | hang on... ah! i got it! that same trick can be applied to grevlut | 11:03 |
| lkcl | ha | 11:03 |
| lkcl | https://ftp.libre-soc.org/2022-05-17_11-05.png | 11:13 |
| lkcl | ghostmansd[m], can i suggest asking Alan, on-list, if he's happy for us to go straight to a dlopen/dlsym plugin system? | 11:15 |
| lkcl | one of the functions-in-the-table would be, "extend the opc-ppc-table with these entries please" | 11:15 |
| lkcl | svp64 will be... a little... ah.. hair-raising | 11:15 |
| lkcl | although if they've already put in the 64-bit v3.1 prefixing then it's a lot less hair-raising | 11:16 |
| lkcl | raise it as a separate bugreport, for discussion, because even discussion you can put down as "to be paid for" | 11:16 |
| ghostmansd[m] | Sure, will do. I also intend to ask about the patches which hang on in mail box. :-) | 11:21 |
| ghostmansd[m] | dlopen/dlsym will have a performance drawback. Also, another performance drawback I see here is that we will have to insert our entries _sorted_ into this table. | 11:35 |
| ghostmansd[m] | Not that I object, I actually like the idea, since it makes us more independent of binutils. | 11:36 |
| lkcl | ghostmansd[m], the performance drawback will be temporary until the SVP64 (and 32-bit) OPF ISA WG Requests For Change (RFCs) are approved | 11:39 |
| lkcl | that's _if_ they are approved of course | 11:39 |
| ghostmansd[m] | Ok then, will ping Alan. | 11:40 |
| ghostmansd[m] | We don't have task for dlopen, do we? | 11:40 |
| lkcl | correct, we don't. do create one | 11:40 |
| ghostmansd | ack, parent is 577 again, right? | 11:42 |
| lkcl | 577... yes. | 11:44 |
| lkcl | no, 550 | 11:44 |
| lkcl | because 550 is binutils-specific | 11:44 |
| ghostmansd | ok | 11:47 |
| ghostmansd | lkcl could you please check 577 833 and 834? | 11:48 |
| ghostmansd | I changed these and want your ack that changes are correct | 11:48 |
| ghostmansd | ah wait they're not | 11:49 |
| ghostmansd | ah no OK | 11:49 |
| ghostmansd | got confused with budget, should be fine | 11:49 |
| lkcl | will check, do run budget-sync | 11:55 |
| ghostmansd | yep, just did it, it complains on 48 and 191 | 11:56 |
| ghostmansd | as it did previously IIRC | 11:56 |
| lkcl | yep good | 11:57 |
| lkcl | and an #837 - dlsym/dlopen for binutils | 11:58 |
| lkcl | cross-referencing the discussion here | 11:58 |
| * lkcl goes looking for links | 11:58 | |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2022-05-17.log.html#t2022-05-17T11:15:10 | 11:59 |
| ghostmansd | yeah already found it :-) | 12:03 |
| ghostmansd | thanks though | 12:03 |
| ghostmansd | Here's https://bugs.libre-soc.org/show_bug.cgi?id=837 | 12:03 |
| ghostmansd | I haven't allocated a budget yet, there's no Alan's confirmation yet that it's OK (will write an e-mail) | 12:04 |
| ghostmansd | And also it cannot judge now how many changes are needed | 12:04 |
| ghostmansd | *I cannot judge | 12:07 |
| lkcl | that's ok it gets adjusted as going along | 12:08 |
| ghostmansd | lkcl, can I submit RFP for 834, mentioning that this one is split between us in RFP body? | 12:26 |
| lkcl | ghostmansd, yes do | 12:27 |
| ghostmansd | pinged Alan et al. about the patches, updated the tasks, submitted an RFP | 12:43 |
| ghostmansd | I'll prepare an email regarding dlopen/dlsym | 12:44 |
| lkcl | ack | 12:56 |
| lkcl | ghostmansd, when you submitted 833, was it a parent of 577 or was it a parent of 550? | 13:08 |
| lkcl | it's absolutely critical not to change these Finanical Records after submission to NLnet | 13:08 |
| lkcl | can you email me the copies of the RFPs please, minus your address and bank details? | 13:09 |
| lkcl | i need to check them | 13:09 |
| ghostmansd[m] | Sure, I'll send these now | 13:38 |
| ghostmansd[m] | Sorry for delay, I was writing an email to Alan | 13:38 |
| ghostmansd[m] | Done | 13:41 |
| lkcl | got it. all good | 14:48 |
| lkcl | toshywoshy, mattermost gone walkies https://chat.openpower.foundation/opf/channels/libre-soc | 15:05 |
| ghostmansd[m] | lkcl, star | 15:05 |
| lkcl | it's not bridging to oftc.net either (not seeing it as a channel user) | 15:05 |
| ghostmansd[m] | I'm done for today, have some deeds outside, will continue tomorrow | 15:06 |
| lkcl | yehyeh i'm done for today and it's only 3pm :) | 15:06 |
| * lkcl salutes | 15:06 | |
| ghostmansd[m] | I hope Alan agrees with plugin :-) | 15:06 |
| lkcl | yeah me too | 15:09 |
| *** kanzure_ is now known as kanzure | 18:15 | |
| excited-mango[m] | Hey, what time in eastern time is the group call? | 20:01 |
| programmerjake | 5pm edt afaict | 20:03 |
| programmerjake | so 1:58 from now | 20:03 |
| programmerjake | excited-mango: ^ | 20:03 |
| excited-mango[m] | Okay cool | 20:06 |
| lkcl | jn: btw librebmc has email notifications going out for the meetings, toshywoshy has the details on how it works | 21:35 |
| lkcl | i attended the meeting last week because i actually (gosh) got a notification that it was happening :) | 21:35 |
| lkcl | if you'd like to get those as well just ask toshywoshy how it happens | 21:35 |
| lkcl | toshywoshy, how _did_ i end up getting a notification? :) | 21:36 |
| lkcl | programmerjake, ping on #yosys, useful discussion potential with jix | 21:40 |
| lkcl | cesar, lxo, excited-mango[m], toshywoshy jn, markos, sadoon[m], meeting 10m | 21:49 |
| programmerjake | i just set a weekly alarm and also have a notification from google calendar | 21:49 |
| lkcl | yehyeh me too :) | 21:51 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
