monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-23 12:09:49 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

added dev logs for 2016-05-08

Browse source
This commit is contained in:
Riccardo Spagni 2016-05-08 23:02:07 +02:00
parent 38c368c0ed
commit 5cdf6a3fc4
No known key found for this signature in database
GPG key ID: 55432DF31CCD4FCD
3 changed files with 245 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
_data/tags.yml
View file

@ -22,7 +22,7 @@
- slug: i2p
name: i2p
- slug: i2p
- slug: i8n
name: Internationalisation
- slug: rpc

117
_posts/2016-05-08-logs-for-the-kovri-dev-meeting-held-on-2016-05-08.md Normal file
View file

@ -0,0 +1,117 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-05-08
summary: Mac / BSD support moving forward
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*May 8th, 2016*
# Logs
**\<anonimal>** Hi fluffypony
**\<fluffypony>** hiiii
**\<fluffypony>** was just about to check if you're around :)
**\<anonimal>** Hi everyone, I think meeting-bot is still online
**\<fluffypony>** yes it is
**\<fluffypony>** coming through loud and clear on this side
**\* anonimal** reading backlog
**\<anonimal>** Hi moneromoo.
**\<anonimal>** Hi psi, uncrustify configs? Can you explain?
**\<psi>** uncrustify is a code styler for c/c++
**\<fluffypony>** I've never heard of it, plz tell me more psi?
**\<psi>** it auto formats the code
**\* psi** gets relevant links
**\<psi>** https://github.com/uncrustify/uncrustify
**\<anonimal>** I know that psi, but why for *.conf?
**\<psi>** i don;t understand?
**\<psi>** what about *.conf?
**\<fluffypony>** oh anonimal
**\<fluffypony>** not for *.conf
**\<fluffypony>** he means conf file for uncrustify matching our coding style
**\<psi>** damn lag
**\* psi** waits to catch up
**\<psi>** fluffypony: right
**\* anonimal** back
**\<fluffypony>** wb
**\<anonimal>** To answer the question, no I don't have an uncrustify config for kovri.
**\<anonimal>** Just a simple .vimrc.
**\<anonimal>** I can take a look at creating a config after #174 is resolved.
**\<anonimal>** fluffypony: I saw your comment in #56, what system are you runnning?
**\<fluffypony>** anonimal: Ubuntu 14.04
**\<fluffypony>** and there's no Boost 1.59 / 1.60 available
**\<fluffypony>** but that little hack worked
**\<anonimal>** 1.54 should work though
**\* anonimal** triple checks
**\<fluffypony>** I can't use 1.54
**\<fluffypony>** incompatible with Monero
**\<psi>** monero needs .56 or higher ?
**\<fluffypony>** .55 or higher
**\<psi>** kk
**\<fluffypony>** so basically .59 or higher if you want both
**\<anonimal>** I need about 5-15 minutes to build on bsd and osx so I can open the new linkage error tickets I talked about in #174
**\<fluffypony>** kk
**\<psi>** :\
**\* anonimal** the only time I have is now and a bit later but the meeting is now so I want to throw it into the topic
**\* anonimal** still compiling, should be done in 5 or so
**\<anonimal>** #monero-dev, FYI, our meetings have always been more organized, on-point, and I've almost always been prepared.
**\<anonimal>** This one caught me off guard.
**\<anonimal>** (last minute suggestion by fluffypony)
**\<anonimal>** Sorry for the wait.
**\<fluffypony>** don't stress, ours are always by the seat of our pants
**\* anonimal** opening tickets
**\<anonimal>** Hmf, I need to work with the bsd a bit more before posting.
**\<anonimal>** Anyway, https://github.com/monero-project/kovri/issues/175
**\<anonimal>** I'm only sitting with this again since I left off < 24 hours or so ago so,
**\<anonimal>** I haven't drawn any conclusions yet.
**\<anonimal>** Has anyone seen this before? #monero-dev?
**\* fluffypony** clicks
**\<fluffypony>** moneromooo: seen anything like that before ?
**\<fluffypony>** "Undefined symbols for architecture x86_64"
**\<anonimal>** The usual 'Undefined symbols for architecture x86_64' has been an osx complaint on this machine in the past.
**\<moneromooo>** Not as such. I've seen plenty of really annoying linking issues though.
**\<fluffypony>** this is gcc on OS X tho, right ?
**\<anonimal>** fluffypony: Yes.
**\<fluffypony>** maybe we're chasing our tails on that
**\<anonimal>** I don't have time to deal with clang. If we want multi-distro builds, I need to streamline our process.
**\<anonimal>** for macosx, clang won't build because it doesn't like the things I did for the reseed rewrite and,
**\<anonimal>** I don't have time to keep-up with llvm development.
**\<anonimal>** So, thoughts?
**\<fluffypony>** rewrite everything in C :-P
**\<anonimal>** lol
**\<fluffypony>** ok my suggestion is that we eschew OS X / BSD compatibility for the moment
**\<fluffypony>** until we can fix Clang support
**\<anonimal>** Thanks moneromoo. I'm glad this isn't just a kovri thing.
**\<fluffypony>** rather than trying to fudge it
**\<anonimal>** Well that's the problem, this won't be the only issue.
**\<fluffypony>** yeah I know
**\<anonimal>** And I'll end up wasting time juggling compilers instead of working on other things.
**\<fluffypony>** I mean that can be a later piece of work
**\<fluffypony>** let's focus on getting it working on one Linux and Windows, where we're running gcc and it's fine
**\<anonimal>** fluffypony: what part will be the later piece of work?
**\<fluffypony>** anonimal: fixing Clang incompatibilities
**\<moneromooo>** I don't use OSX btw, so kinda ignore what I said above.
**\<anonimal>** Ok sounds great, I'll focus on linux/win building.
**\<anonimal>** Should we remove osx/bsd build instructions from BUILDING.md?
**\<anonimal>** Or I'll just open the bsd ticket and maybe someone will see it?
**\<fluffypony>** yeah, I think let's make a note that it's broken on OS X / BSD for the moment, and that contributors are welcome to fix
**\<fluffypony>** kk
**\<anonimal>** Ok, I'll add the note.
**\<anonimal>** Any other questions/comments on #175?
**\<fluffypony>** no not yet
**\<fluffypony>** I mean no not atm, lol
**\<anonimal>** Ok, I'll add a note in #174 about what we discussed.
**\<anonimal>** And part 1) in #174, apparently there is an env variable I can set to get it to work.
**\<anonimal>** Not the first travis issue I've had to deal with.
**\<anonimal>** Oh well, they are growing quite nicely IMHO.
**\<fluffypony>** travis issues are growing quite nicely ?
**\<anonimal>** lol, yes, and I meant their project as a whole.
**\<fluffypony>** lol
**\<anonimal>** Ok, hour is up. Anything else pressing?
**\<fluffypony>** I don't think so - this was kinda an interim meeting because Kovri's was last week
**\<fluffypony>** so this brings them into line
**\<fluffypony>** next one on May 22nd, same time
**\<anonimal>** Ok, I'll mark the calendar.
**\<anonimal>** Thanks everyone.
**\<fluffypony>** thank you

127
_posts/2016-05-08-overview-and-logs-for-the-dev-meeting-held-on-2016-05-08.md Normal file
View file

@ -0,0 +1,127 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-05-08
summary: Clarification on ringCT next steps, 0MQ, discussion of open PRs
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*May 8th, 2016*
# Logs
**\<fluffypony>** hyc, moneromooo, smooth, luigi1111w, luigi1112, luigi1114, ArticMine, NoodleDoodle, tewinget: meeting starting
**\<hyc>** hey
**\<fluffypony>** and othe
**\<fluffypony>** just waiting for the relay to come up
**\<fluffypony>** there we go
**\<luigi1112>** Not here
**\<fluffypony>** hello, and welcome to the 75th annual hunger games
**\<bigreddmachine>** crap, luigi1112's not here.
**\<fluffypony>** luigi1112 is literally a ghost
**\<fluffypony>** ok so we have a couple of PRs hanging around
**\<bigreddmachine>** is that why there are always 2-3 of him?
**\<fluffypony>** bigreddmachine: exactly :)
**\<luigi1112>** Hoooooo can say
**\<fluffypony>** I've reviewed #831 and it's ready for merge
**\<fluffypony>** same with 827
**\<fluffypony>** has anyone had further thoughts on 818 or are we ok with merging that functionality in its current form ?
**\<fluffypony>** bearing in mind that this will haunt us basically forever
**\<fluffypony>** and we pretty much can't change it ever again
**\<fluffypony>** no pressure or anything
**\<fluffypony>** (just kidding, we can definitely version it)
**\* fluffypony** waaaaaits
**\<hyc>** I haven't looked at 818, it's a crypto question still
**\<fluffypony>** yeah I think shen looked at it
**\<fluffypony>** ok we'll put a peg on that pending input from moneromooo and smooth
**\<ArticMine>** What are shen's thoughts on 818?
**\<MRL-Relay>** {-shen} I took a glance at it, but if desired I can look deeper
**\<MRL-Relay>** {-shen} at glance looked ok
**\<fluffypony>** shen: I think take a closer look if you can, given how we \*are\* stuck with it forever we may as well try get it right off the bat
**\<MRL-Relay>** {-shen} ok I will budget some time today or tomorrow
**\<fluffypony>** ok cool
**\<fluffypony>** then with the performance branch (794) we found an issue with the initial migration, messed up a global index on some txos
**\<luigi1112>** Is that the sig thing?
**\<fluffypony>** this appears to be fixed with the new / faster migration
**\<fluffypony>** luigi1112: yes
**\<luigi1112>** Ok
**\<fluffypony>** luigi1112: also I think if you have a second do you want to glance at the output format, maybe we need to give it a version prefix and a suffix of some sort
**\<fluffypony>** ok so performance is ready for merge, unless anyone has an objection
**\<hyc>** sounds good to me
**\<fluffypony>** then 810, I'm still unclear as to whether we're dropping that idea or we're merging it
**\<hyc>** given the increased locking requirements I'm against it.
**\<fluffypony>** ok
**\<hyc>** and as said before, I think fixing the pool code to use cheaper queries is better
**\<fluffypony>** I'm onboard with that
**\<fluffypony>** so now that we're getting the performance branch out the way
**\<fluffypony>** the next two major things on the radar are 0MQ and ringct
**\<fluffypony>** at the moment we have that stall in the dev branch, not sure whether it's time to nuke it and start the new one
**\<fluffypony>** I'll wait for input from moneromooo on that
**\<fluffypony>** and then ringct - hyc, did you say you were going to do some of that? I can't even remember
**\<hyc>** I looked into it but no, moneromooo should take lead
**\<fluffypony>** ok
**\<fluffypony>** shen
**\<hyc>** I can do whatever DB additions are needed
**\<fluffypony>** what's the status of your implementation code ?
**\<dEBRUYNE>** perhaps hyc can assist with the DB stuff
**\<dEBRUYNE>** oh he was quicker than me already
**\<MRL-Relay>** {-shen} Should be ready for test net at least
**\<fluffypony>** ok
**\<fluffypony>** it's time for a testnet fork anyway, so we can work towards that
**\<fluffypony>** basically everything else requires moneromooo and smooth, so we can put a peg in them till next meeting
**\<fluffypony>** speaking of which
**\<fluffypony>** next one on the 22nd
**\<dEBRUYNE>** perhaps they will show up within the next 30 minutes :-P Just page them 3 times!
**\<fluffypony>** hah hah
**\<dEBRUYNE>** Btw fluffypony, will the performance branch be used for a new point release?
**\<fluffypony>** dEBRUYNE: yes
**\<dEBRUYNE>** All right
**\<dEBRUYNE>** Btw, if moneromooo and smooth show up later tonight and have a chat about 0MQ we could just add that to the dev logs
**\<fluffypony>** ok
**\<bigreddmachine>** q: for the next point release... will it include arm7 binaries? 0.9.4 does not
**\<fluffypony>** it should
**\<bigreddmachine>** okay. unreleated, probably for hyc... you mentioned that simplewallet now only needs to sync ~30 MB instead of 3 GB with the new improvements. What was the savings? was there just a lot of data being shared that was unnecessary?
**\<luigi1112>** fluffypony: I'll think about that
**\<hyc>** bigreddmachine: sync of irrelevant blocks, only needed to use hashes
**\<bigreddmachine**> kk, thats what i figured
**\<bigreddmachine>** now just syncing block headers?
**\<hyc>** up to a given refresh height it only syncs hashes
**\<fluffypony>** moneromooo: we can carry on chatting about the bits you missed after the kovri meeting, if that's ok ?
**\<moneromooo>** Sure.
**\<fluffypony>** ok back to the Monero side
**\<fluffypony>** moneromooo: have you had a chance to read the meeting backlog ?
**\<moneromooo>** I did.
**\<fluffypony>** ok - thoughts on 0MQ / dev branch?
**\<fluffypony>** if you have the dev branch on your fork we can nuke it and reset
**\<moneromooo>** I think you can nuke the dev branch.
**\<moneromooo>** As for 0mq... whenever I get to start it, it's going to be a largeish amount of work at once I think.
**\<fluffypony>** ok
**\<moneromooo>** I happen to be not super motivated to code these days, after day job spent debugging stuff.
**\<fluffypony>** sometimes you gotta take a break and work on fun stuff
**\<dEBRUYNE>** perhaps Ring CT qualifies as fun stuff, perhaps not :-P
**\<moneromooo>** What's more important btw, 0mq or ringct ?
**\<fluffypony>** I would think ringct
**\<dEBRUYNE>** I'd say Ring CT too
**\<dEBRUYNE>** Iirc ring CT needs to be some time on testnet too anyway
**\<moneromooo>** And we can ask the "did nobody test this ?" peanut gallery in to test it :D
**\<fluffypony>** awesome
**\<moneromooo>** One other thing I wanted to do, which is interesting from a user's point of view, is to allow the wallet to see/decode pool txes.
**\<moneromooo>** That's probably not too much work.
**\<dEBRUYNE>** lol moneromooo
**\<dEBRUYNE>** Btw moneromooo, in case you hadn't read it yet hyc can assist you with the DB stuff
**\<dEBRUYNE>** More specifically -> \<hyc> I can do whatever DB additions are needed
**\<moneromooo>** I saw that. It's good so I don't break it all.
**\<dEBRUYNE>** Btw fluffypony, I forgot to ask earlier. Not sure if he is here, but any plans to opensource NoodleDoodle's trezor code soon^tm?
**\<fluffypony>** you'd have to ask NoodleDoodle that
**\<dEBRUYNE>** all right, perhaps he responds :-P
**\<moneromooo>** Oh: about reviewing the signature patch, IIRC smooth said that code was only used for the debug commands, so the CN people might not have make it so resistant to misuse or something. So might be worth looking at its internals (I expect it uses the same building blocks as ring signatures, but I don't really know).
**\<dEBRUYNE>** Also, regarding #810, a pool op commented the following: "Adding this to the current HEAD 8b0d22a reduces CPU by an order of magnitude on a pool wallet: 80% usage on a core down to 8%. Seems like a significant performance win to me." Since there is a mixed feeling about the PR itself I figured perhaps just close it and send the pool ops a mail that they could possibly apply the code/patch to their own code if they want to do so. I could
**\<dEBRUYNE>** gather email addresses and setup a standardized mail.
**\<dEBRUYNE>** ^ fluffypony
**\<moneromooo>** Changing the pool code to call getinfo and check top hash would also drop CPU usage a lot.
**\<fluffypony>** shen, see above ^^
**\<fluffypony>** (before the pool code stuff)
**\<MRL-Relay>** {-shen} ok
**\<MRL-Relay>** {-shen} good point
**\<dEBRUYNE>** moneromooo: I see, well then it's more up to the pool ops instead of the contributors/developers imo
**\<moneromooo>** Up to whoever gets his butt in gear to do it, as usual :D