IRC logs for #openrisc Tuesday, 2014-05-27

--- Log opened Tue May 27 00:00:07 2014
stekernblueCmd: nice cleanups, there was a lot of stuff in there that I have been wondering "there got to be a better way to do this in python, wonder how"05:24
olofkIt was better before that05:26
stekernespecially the if bla: return quartus if bleh: return ise05:26
stekernolofk: you're just suffering from decorator withdrawal right now ;)05:39
olofkblueCmd: RFCoC06:32
olofkRequest for comments on comments. But I liked your link better06:35
olofkTime to go out in the garden and do some decorating to help with my python withdrawal06:36
stekernsounds nice, but watch out for snakes!06:37
stekernit's cold and rainy here today though, first day in a week or two I'm not sorry I've got an indoors job06:39
_franck__blueCmd: I think something like that in the system core file will be more clear:
stekernare those two different suggestions?06:57
_franck__I knew that wasn't clear when I pasted it :)06:57
_franck__the one at the top is blueCmd's suggestion06:58
_franck__mine is at the bottom06:58
stekernoh, right, I see now06:58
stekernfrom a .core file perspective only, I think I like the latter better06:59
stekernolofk: where's your coc?07:01
olofkMy proposal is like something inbetween the two alternatives in _franck__'s pastie07:30
stekernI wonder why your coc doesn't show in the pull request, and there was no notification about it07:37
stekernmaybe it was censored...07:38
olofkGrrr... that happens all the time when I try to show my coc07:40
olofkI added another comment now07:41
stekernah, there was no pull-request for that07:52
olofkblueCmd: Isn't collections.default_dict() just the same as {}?08:17
olofkTrying to figure out what you're doing here08:17
olofkNope. I don't understand08:22
olofkto_generate = collections.defaultdict(lambda : collections.defaultdict(list)) ?08:23
olofkIs it just a dict of dicts?08:23
olofkOr a dict of dict of lists?08:23
blueCmdolofk: the difference there is that when you reference something that doesn't exist, the generator is ran and fills it08:40
blueCmda = {}08:40
blueCmdthaht doesn't work08:40
blueCmda = collections.defaultdict(list) does08:41
blueCmdand the thing i do is dict of dict of list08:41
blueCmd_franck__: yes, agreed - I like your idea better08:44
blueCmdolofk: replied via mail which github screwed up a bit, but you're a smart man I'm sure you will figure out how to read it :)09:00
olofkAh cool dict trick. Didn't think of that09:11
stekerndo a trick with your dict and I'll show you my coc?09:13
stekern...I'll be quiet now...09:14
olofkWhy the hell doesn't the 'r' shortcut for reply work for me on github09:19
olofkgtg. More comments later, but basically I think we're on the same page now09:20
olofkblueCmd: I'm not following you why core: would be better than generate:. I don't mind either way, just feel that I missed something11:23
kyrre_hi, im experiencing somthing weird with or1ksim.. im watching the cpu_state.pc which holds the program counter, at some point in my program it makes a huge jump, to a location outside of my program, and then enters a loop. When i check the executed log, i cant see the program counter for the adress wich it loops11:53
LoneTechit might not actually be executing anything there. it could be looping an exception such as instruction fetch bus error or illegal instruction.11:55
kyrre_ill see what i can find11:57
LoneTechwhat address was it?11:59
kyrre_breaking on except_handle i cant see that its processing an exception, or did you mean an exception produced outside of my simulator?11:59
LoneTechmost likely inside11:59
kyrre_e59c - e5a012:00
kyrre_rins and repeat12:00
LoneTechnot normally a part of the exception range. still, the or1k is designed to just loop in place if it tries to execute zeroes, so perhaps a misdirected branch brought it there.12:01
blueCmdolofk: because it can be a section for all core configs12:02
kyrre_ye, that was my assumtion but the adress wich brind it theer is 8590 which is a addi12:02
blueCmdolofk: let's say we add a 'validate' step (not sure what it would do, but bear with me), in your case it would require an addition of [validate:wb_intercon]12:02
blueCmdalso, 'core:' is shorter :)12:03
blueCmdolofk: I've ran a code formater on FuseSoC, the diff is huge - is that something you want to apply?12:05
kyrre_ive found where it enters the loop in the execution log now12:07
LoneTechwhat's before the addi?12:09
kyrre_the last instructions before the addi (including addi at the end) : l.lwz   |   l.jal  misc_int_handler  |   l.lwz   | l.sw   |    l.addi12:17
LoneTechso a store word. shouldn't branch by itself. I don't know what's happening12:19
kyrre_the store word is the first in the misc_int_handler12:21
kyrre_this is not the first time ive experienced weird jumps12:21
kyrre_have had other times when it jumps to places it shouldnt. like 508 which is one word beyond an exception handler12:22
stekernwhat's after the l.addi?12:33
stekernand, what version of or1ksim is this12:34
kyrre_EXECUTED(     116719): 0000e59c:  0000000012:34
kyrre_OpenRISC 1000 Architectural Simulator, version 2012-04-2712:35
kyrre_but i have added a module12:35
kyrre_e59c is an adress outside of my program12:36
stekernI meant, next instruction that comes after the l.addi in your program12:36
kyrre_then another addi12:36
stekernand that version number doesn't say anything (we should fix that), I meant where did you get it from svn/git/prebuilt somewhere12:37
kyrre_ive had problems with using stable releases for or1k-gcc12:38
stekernkyrre_: could you try this?
kyrre_i can try, but probably gonna take me a while to add my changes to it12:42
kyrre_the problem persists even if i disable my module, so lets see12:44
stekernwhat kind of machine do you have (64-bit, 32-bit etc)12:46
kyrre_ubuntu 14.0412:46
kyrre_collect2: error: ld returned 1 exit status12:46
kyrre_make[2]: *** [sim] Error 112:46
kyrre_make[2]: Leaving directory `/home/kyrre/or1ksimGIT/bld-or1ksim'12:46
kyrre_make[1]: *** [all-recursive] Error 112:46
kyrre_make[1]: Leaving directory `/home/kyrre/or1ksimGIT/bld-or1ksim'12:46
kyrre_make: *** [all] Error 212:46
stekernthere was a lot of issues with earlier versions of or1ksim and 64-bit machines, but nothing that severe I think12:47
stekernkyrre_: use some paste service (pastie/pastebin) and paste the actual error too12:48
kyrre_the output from make12:50
stekernand that's after a: ../or1ksim/configure && make12:54
kyrre_tried the string i use to configure the or1ksim im currently using: ../or1ksim/configure --target=or32-elf --prefix=/opt/or1ksim CFLAGS="-O0 -g -Wno-unused-but-set-variable"12:57
kyrre_both return in the same error12:57
stekernI just tried building that on a similar machine as yours, without problem12:59
stekernkyrre_: you can try this binary, just to check the original issue:
kyrre_is it built with -g?13:02
stekernnope, but I can rebuild it with that if you want13:02
kyrre_would be easier to verify13:03
stekernI have never ran or1ksim in a debugger... ;)13:04
stekernwhy would you need to do that?13:04
kyrre_because im modifying or1ksim13:04
stekernok... with your CFLAGS I get the same error13:05
stekernbut you got them with ../or1ksim/configure && make as well13:06
stekernok... but can you confirm if the binary I gave you have the original issue anyway13:08
stekernyou don't need -g to do that13:08
kyrre_i cant find the issue in that one13:11
stekernit seems like it's the -O0 that causes it on my side, I've updated the sim to one compiled iwth -g now13:13
stekernok, so that works. Then it's kind of determined that it's an issue with the svn version13:15
kyrre_hm.. the -g version just stopped responding in gdb13:16
kyrre_its stuck at the same adresses13:16
kyrre_so that means its either an issue with my code or or1ksim?13:16
kyrre_but since my code shouldnt result in this behavior its most likely or1ksim13:17
kyrre_ill recheck the execution logs and check vs the dissasembly again13:18
stekern? can you reproduce the behaviour with the one compiled with -g?13:19
stekernbut not in the one that wasn't compiled with -g?13:20
kyrre_im not sure how to catch the error from the "top" (if that makes sence)13:22
kyrre_but yes13:22
kyrre_ive got watcpoints watching the cpu_state.pc and looking for that specific address, not sure how to watch the pc from the program13:24
stekernwell, doesn't it just get stuck at that address?13:32
kyrre_it executes til its stuck, but ctrl+c doesnt return to promt13:36
stekernnot sure I follow?13:38
stekernthat certainly sounds like or1ksim have crashed then13:39
kyrre_ye, cause its stuck in that loop13:39
kyrre_its still running13:39
kyrre_im not sure how i can verify that its the same issue13:39
stekern_your_ program is stuck in the loop, but or1ksim should still be responsive13:41
kyrre_it jumps to e95c13:43
kyrre_there it has a l.j 0xe59c13:44
stekernbut why isn't or1ksim working after that?13:45
kyrre_it works with the gdb stepi command now13:45
stekernok, let's put aside running it in gdb... does it or does it not work when you run it normally?13:46
stekerncan you give me your binary?13:47
kyrre_or1ksim not in gdb produces the same result13:48
kyrre_the loop in e59c13:48
kyrre_it jumps there when its trying to jump to 0x551c13:48
stekernthanks, I'll try running it here in a short while13:51
inigomI would like to know if someone has made profiling using OpenOCD. I have tried with both simlators (icarus and verilator) and with the de0_nano board. I'm running an simple enless program. I always get Segmentation Fault.13:56
_franck__I never used profile with openocd. I don't know what it does.13:59
inigomok thanks!14:00
_franck__"Profiling samples the CPU PC as quickly as OpenOCD is able, which will be used as a random sampling of PC."14:00
_franck__inigom: can you tell me more about openocd profiling ?14:01
inigomI want to use it to check the execution of code in OpenRISC14:05
_franck__ok, so it read target's PC as fast as possible and saves the result in a file14:06
_franck__inigom: do you want to check the execution of your program in simulation ?14:06
inigomYes and also in the board14:07
inigomand to check what is doing OpenRISC with that code14:08
_franck__do you need RTL simulation ? is or1ksim a possible alternative ?14:08
_franck__I'll try this profile command and try to fix this segfault14:11
inigomi would like to use RTL. But I'll have a look in or1ksim14:24
stekernkyrre_: it doesn't seem to stall here.14:25
kyrre_for me it stops after misc int handler is called with the arg -67309978014:26
kyrre_after the misc int handler and stepi onwards14:28
stekernbut if you just run your program in or1ksim compiled without -g?14:30
stekernthen it stalls, after how long?14:32
kyrre_trying to narrow it down14:32
kyrre_think i found it14:33
stekernhere it just forges on when I run it with: sim -t -f ~/sim.cfg rtosdemo.or3214:35
kyrre_i have found a point with gdb where its says "0x858c <misc_int_handler>        l.j 0xe59c    <xHeap+12064> "14:37
kyrre_but that is not hat it says in the dissassembly file14:37
LoneTechso the instruction fetch seems to have read 0x6010 at 0x858c14:38
LoneTechor is it 600c? no matter14:39
kyrre_i have defined 0x6000+(d10) to a spr register for my module14:40
stekernif you read that address from within or1ksim, what do you get then?14:41
kyrre_cannot acces memory14:41
stekerni.e.: (sim) dh 0x858c14:41
kyrre_never used the sim like that before14:42
kyrre_(sim) dh 0x858c14:42
stekernI'll repeat the question then, does it stall when you run or1ksim like this: sim -t -f ~/sim.cfg rtosdemo.or3214:42
stekernthat's not right14:43
kyrre_its running14:43
stekernso... what are you doing when it's not working...14:44
stekernstep by step ;)14:44
kyrre_it ends up in the loop14:44
LoneTechno idea what 1804 is, a5 looks like a test pattern, and then there's the array of sequential values. has it overwritten its code with data?14:44
kyrre_with sim -t -f ~/sim.cfg rtosdemo.or3214:44
stekernok... so "it's running" was not a confirmation that it does *not* stall...?14:45
kyrre_it was a confirmation that i had started it14:45
stekernah, ok14:45
stekernand then it stalls?14:45
stekernso what's different in your and mine setup?14:45
kyrre_as in repeats the e59c e5a0 loop14:46
stekernyes, it does not do that here14:46
LoneTechperhaps you simply have enough RAM?14:46
kyrre_on my computer? or in the simulator?14:47
LoneTechthough I don't think or1ksim actually does simulate unwired address lines (causing mirrored RAM views in normal hardware)14:47
stekernto make sure, try with my sim.cfg:
stekernand download the sim again from here:
kyrre_same result with simcfg14:49
kyrre_dl sim again14:49
kyrre_its  still endinf up in that same loop14:51
kyrre_are you running it "long enough"14:51
kyrre_but doesnt take that long on my comp14:51
stekernI've had it running for 5 min now14:52
kyrre_running the new sim with your sim.cfg with the rtosdemo from my dropbox14:52
kyrre_ends in the loop14:52
kyrre_with the same command you posted14:53
stekernjust to make sure that you run the right sim: ./sim -t -f ~/sim.cfg rtosdemo.or3214:54
kyrre_./sim -t -f ~/sim.cfg rtosdemo.or3214:54
kyrre_copy pasted from last comand :)14:54
stekernLoneTech: can you try?14:54
stekernI'll try on my laptop too14:55
stekernworks fine on my laptop too14:58
kyrre_this is realy weird15:00
stekernsure is...15:01
LoneTechone moment15:02
kyrre_if i stop gdb right after i start it, and prints dh 0x858c15:02
kyrre_which is the same as what you pasted earlier15:03
stekernyes, and that matches what's in rtosdemo.or3215:03
stekernput a printf on writes to that or1ksim then15:04
stekern(or breakpoint, or whatever you fancy the most)15:04
stekern*on writes to that in or1ksim15:04
stekernto 0x858c I mean15:05
_franck__rtosdemo.or32 works fine here15:05
LoneTechran it for a while, expected code at 858c still. not overwritten yet.15:05
stekernok, so something is off with kyrre_'s machine, would be interesting to know what...15:05
LoneTech1700008 cycles15:06
stekernon a different matter, I'm getting closer to mr heisenbug15:07
stekernI've isolated a situation where both processors are waiting for a spinlock with irq's turned off15:09
kyrre_struggeling to break on that memory adress15:11
kyrre_getting cand access memory when i try to examin it15:12
stekernso just put a printf in the or1ksim memory access function15:12
stekern(you can get back to the version you can compile, since that's not the issue here)15:13
kyrre_which function is that?15:14
kyrre_found it15:19
kyrre_at pc = 0x176c  it writes to that adress15:23
stekernso, the sp is getting screwed... but again, why only on your machine?15:24
kyrre_its a weird issue15:25
kyrre_this isnt an issua i would expect to differ on machines, yet it does15:25
kyrre_at 176c its an l.sw 0(r1), r915:26
kyrre_in a context switch when its about to handle an exception15:27
stekernso... what exception is that?15:30
stekernis that expected?15:46
LoneTechI have to go15:46
kyrre_yes it is15:48
kyrre_thanks for the help LonTech15:48
stekernhow can this be ok?
stekerntickets is a struct containing two 16 bit variables - owner and next15:52
stekernthat struct is written as 32-bit here:
stekernso, what is restricting the following scenario on arm?15:53
stekerncpu0: load (lock->tickets.owner)15:54
stekerncpu1: load tickets15:55
stekerncpu1: modify tickets15:55
stekerncpu1: write tickets15:55
stekernerr... wait15:56
stekernlet's continue ;)15:58
stekerncpu0: modify tickets15:59
stekerncpu0: write tickets (and overwrite what cpu1 just wrote)15:59, that should be fine, the atomic should of course protect that...16:00
stekernit's good thinking out loud some times ;)16:00
stekernno, wait, the atomic is only on cpu1...16:01
kyrre_:) im not able to follow in in the middle of hunting down the location in my code where it sets the stackpointer to a subpar place16:02
stekern...and cpu0 is only modifying the lower part of the word...16:03
stekernthat should be all fine16:03
stekernmaybe there's a bug in the mor1kx atomics implementation16:08
kyrre_hehe, not a chance to follow you there, but ive found out more about my problem..  the stack pointer gets moved to the location where misc_int_handler is stored, how? not sure16:11
kyrre_the whole misc int handler gets overwriten at that point, but how this only happens on my computer..... anyways i have to go now16:18
kyrre_thanks for the help +stekern16:18
stekernI think I know what the problem is16:34
stekernwallento: I don't think snooping in the arbiter is going to work16:35
stekernbecause, I think what's happening is, the l.swa has succeeded into the storebuffer before the other cpu's store has made it to the wishbone arbiter16:36
stekernI'll confirm this, but I'm thinking that we should add a "snoop_out_addr" that is hooked up directly to the the signals that are connected to the input of the storebuffer16:37
stekernand then have a seperate "snoop unit" that handles them16:38
stekernI think that will align with the cache-coherency as well16:39
stekern...I kind of like not depending on a bus arbiter that can do snooping too16:47
stekernafter a walk with the dog I realised that that's not going to work, then you'll have stores in flight that will not break the l.lwa/l.swa link17:19
stekernmaybe the l.swa just have to wait out the storebuffer17:19
wallento hey sorry, I will come back to this topic tomorrow, in the middle of writing a paper17:23
wallentothe store buffer may need an extra input for snooping17:23
wallentobut the snooping should come from the bus, don't forget that there may be other masters17:24
wallentofor me thats the main reason to snoop in the beginning, as my DMA controller overwrites my message buffers17:24
stekernwallento: no, hurry, that gives me more time to ponder about it ;)17:27
stekerns/no, hurry/no hurry17:28
wallentoi will definitely come back to snooping on the weekend (extended due to holidays in Germany)17:28
stekernand yes, I realised what you just said during the dog walk17:28
wallentoI should get a dog17:29
olofkblueCmd: (core:) General configuration of other cores is an interesting use case. I think we should take a few minutes to think if we can come up with anything there18:53
olofkThat might actually be an alternative to the gentoo style use flags that I have been wanting to introduce18:55
olofkAnd the coding style diff... I'm all for consistent whitespace, but some of the other style fixes seem more arbitrary18:55
olofkBut if that is standardish I guess it's a good reason to apply it18:56
blueCmdolofk: it's PEP8-ish. some things are just to try to keep the line length under 80 char - when it fails the result isn't better than the original.18:59
blueCmdI thought that it's easier to fix them when I modify the relevant file later19:00
olofkYes. It's probably more work to go through the patch and unPEP8ify a few things.19:02
olofkhmm... should I pick this before your other patches?19:03
blueCmdno, it's based on the others19:04
olofkah ok..19:05
blueCmdand it's autogenerated so it's very easy to apply last19:05
blueCmd(almost autogenerated at least)19:05
olofkCool. I'll start working on the pull request then19:05
olofkrfcoc on first patch19:17
stekernmy 2 cents on major whitespace clean-ups - I think it's better to apply such as you modify things around the "offender"19:20
stekernand then you _first_ apply the whitespace fix, then the change19:21
stekernbecause then you can back out the change (which might contain bugs), without needing to back out the whitespace fix19:22
olofkstekern: I think I'm with you on that actually. The issue right now is that blueCmd has already prepared some patches for the old white space19:23
olofkBut if it's not too much work to rebase them after the ws cleanup, I think that would be best19:24
stekernI think either is probably fine in this case19:27
olofkblueCmd: Seeing that you're handy with python, can you come up with a better way than the sed hack for > fusesoc to handle installations outside of PYTHONPATH?19:29
olofkblueCmd: I picked and pushed the three least controversial patches19:38
blueCmdolofk: what does it do?19:38
olofkIt finds where the fusesoc module is installed and adds it to PYTHONPATH for the fusesoc binary19:39
olofks/exeuta... eh.. you know what I mean19:40
blueCmdah yes I see19:40
blueCmdwhat problem does it solve?19:40
olofkThe default behaviour is to install to /usr/local, but python won't look for modules there19:40
olofkAt least not on my distro19:41
olofkWhich is the most awesome distro19:41
blueCmdright, but why do you need that?19:41
blueCmdI mean, it should look at it's local directory19:41
olofkBut the fusesoc exectuable ends up in /usr/local/bin19:41
blueCmdI would probably change that part19:42
blueCmdhave a shell script there instead19:42
blueCmdor something19:42
olofkA shell script that launches the fusesoc python module?19:43
olofksorry..not module19:43
olofkThe entry point19:43
blueCmdyeah, but I think this can be solved better still thinking of it19:44
blueCmdlet me play a bit19:44
olofkBe my guest. I've used this trick since it's what I have seen other people do19:44
olofkAnd I'm NOT switching to fucking distutils/setuptools/distribute/whatever19:44
blueCmdwhat's your distro?19:46
blueCmdright, because it works without that code in debian19:48
olofkWhat's in sys.path?19:49
blueCmd>>> import sys19:49
blueCmd>>> sys.path19:49
blueCmd['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/pymodules/python2.7']19:49
olofkI never fully understood the difference between site-packages and dist-packages19:49
olofkMy fusesoc installs itself in /usr/local/lib64/python3.3/site-packages/fusesoc19:50
olofkah ok, so it's a debian thing19:51
blueCmdstill, is that path you listed in your sys.path ?19:51
olofk>>> import sys19:51
olofk>>> print(sys.path)19:51
olofk['', '/usr/lib64/', '/usr/lib64/python3.3', '/usr/lib64/python3.3/plat-linux', '/usr/lib64/python3.3/lib-dynload', '/usr/lib64/python3.3/site-packages']19:51
blueCmdso why are you installing there? :)19:51
olofkYes, I know, but it's the default.. and people like to install to /opt or in their home dir19:52
olofkA shell script still sounds like the best way so far.19:53
blueCmdNot really, I like having the script in /usr/local/bin19:54
blueCmdand regret saying the thing about shell script :)19:54
olofkIt's not a big deal really, but it would be nie to get rid of that single thing that make does19:55
olofkHave you looked at my grumpy comments on your pull request?19:58
blueCmd"I don't think it would hurt to keep the Provider base class even if it's just becomes an empty class after this"19:59
blueCmdit does hurt19:59
blueCmdit doesn't provide anything and adds complexity19:59
blueCmdIf you _really really really_ need to fullfill your interface fetish (even though that is not something python does), use
olofkNo, it doesn't provide anything, but you can't call two fucking lines of python added complexity :)20:00
blueCmdolofk: I can call a new file with a class that everything will inheirit complexity yes20:00
blueCmd# of lines are not relevant20:01
olofkI don't really have a strong opinion here. Just thought that we will probably return to using a base class in the future and that it's already there20:01
blueCmd[sin(int(x)) for x in sys.argv] if sqrt(len(sys.argv)) else setattr(None, 'tomato', 7)20:01
blueCmdthat's quite complex20:01
olofkJesus christ20:02
blueCmdolofk: python uses implicit interfaces, please use them :(20:02
olofkYes.... that's complex20:02
olofkYes. The explicit interfaces were a bad idea20:02
blueCmdolofk: I cannot argue with you on these things more than 'It is not pythoney'20:02
blueCmdultimately it's up to you20:03
stekernpythoney or not, having things without users lingering around is generally a bad idea20:14
olofkJust to make it clear, I'm not arguing for keeping the interface functions. Just keeping a Class Provider:\n\tpass20:15
stekern...another 2 cent drive-by comment ;)20:15
olofkWhich is sort of what you did here
blueCmdre: moving sections from __init__. Generally I frown upon "I'm thinking of X" - do X and do it nice, or don't do X and do that nice - don't do something in the middle :)20:19
blueCmdolofk: for what?20:20
blueCmdah the Error?20:20
blueCmdNo, that's a recommendation how to do custom Exceptions20:20
blueCmdthat way it's very easy to do except section.Error: to catch all section related errors20:20
olofkAh ok... I ehhmm.. followed a guide on how to do custom SoC framework provider submodules, and that clearly stated that there should be a Provider base class :)20:21
olofkI'm not turning down a ready-made patch, so I'll pull that one tomorrow or later tonight20:22
_franck_this cfi_ctrl is totally broken for CFI parts with 8-bits data interface20:22
olofkBut regarding sections, I don't think there's any sense in moving it back into the main fusesoc module20:23
stekernwhy was it moved out from there in the first place?20:24
stekernI know there was some thought behind that, but can't remember20:24
olofkBecause I sensed that it would grow20:24
blueCmdolofk: I'm allergic to contents20:24
olofkSo I moved it while it was still new20:25
olofkblueCmd: Then we have a problem :)20:25
blueCmdolofk: fusesoc/super/__init__.py20:25
blueCmdolofk: what is in that file?20:25
blueCmdwhat is in that file?20:25
olofkNot following you..20:26
stekernI wonder if it should be 'pythonesque' instead of 'pythoney'?20:26
olofkIs a special file?20:26
olofkpythonic, I think20:26
olofkBut I like the honey in pythoney20:26
stekernthat doesn't sound fancy enough...20:27
olofkMost of the contents came as a result of my factory submodule fumbling, and most of it looks like shit20:31
olofkBut with the section submodule, I think I reached the pythonian nirvana20:32
blueCmdolofk: the thing I wrote above, they are two hypthetical files20:32
blueCmdcontaining the same code20:32
blueCmdwhich filename is clearer?20:32
olofkDefinitely, but it's so damn ugly to do from fusesoc.sections.loader import Loader20:33
olofkThat's my main reason20:33
olofkI like from fusesoc.sections import Section20:33
blueCmdyeah, and that brings me to another cleanup I want to do :)20:34
blueCmdfrom fusesoc.sections import loader20:34
blueCmdI hate namespace polution, but I'm not expecting to convince you on this one20:34
blueCmdalso, it's easier to not require imports for every single f*king thing you want to use20:35
olofkIs a standardized name where you expect to find a submodules class definition+20:36
blueCmdfrom fusesoc import util20:36
olofkI'm with you on that one20:36
blueCmdolofk: no, it's just an example20:36
olofkBecause, if I get kidnapped by an evil scientist that removes all memories of my Open Source project and I want to return to FuseSoC, I would probably look for the Section class in fusesoc.section, rather than in fusesoc.section.loader20:37
blueCmdI would look for Section class in fusesoc/ and the implemented sections in fusesoc/sections/vhdl.py20:38
olofkahh.., but a sections submodule20:39
olofkThat's sneaky20:40
blueCmdI know!20:40
olofkI got a bit pissed when I realized that you couldn't have and a poop submodule in the same dir20:40
olofkIs _that_ somewhat standard pythonesian?20:40
blueCmdsection and sections?20:42
blueCmdthat is totally my own preference20:42
blueCmdthere are people who just looove to put everything into __init__.py20:43
olofkClass definition in and subclasses in items/subclass.py20:43
olofkI didn't like it, but couldn't really figure out a better way to do it. There have been some weird side effects from that as well20:44
olofkLike some circular dependency20:44
blueCmdI don't think there is a more pythony way to place/name things (unless you go extreme)20:44
blueCmdcurrently I'm just arguing for you to adopt my own preferences20:44
olofkYeah, I know, and I'll probably pick up a few of them20:45
olofkBut I still like my from fusesoc.section import Section20:46
olofkBut wait...20:46
olofkCurrently only fusesoc.section knows about the subclasses, thanks to the mega cool factory, so the subclasses could move to a sections directory and fusesoc/section/ could transform into fusesoc/ and no one would notice a shit20:47
olofkThe same thing should apply to the other submodules20:49
olofkI don't think it will work for the other modules right now, but it shouldn't require much to fix this20:50
blueCmdfrom fusesoc.simulator.simulator import Simulator20:52
blueCmdyo dawg20:52
olofkYes. That stings in my eye20:52
olofkI almost started crying when I tried to find something prettier20:53
olofk...and failed20:53
blueCmdthere there20:53
blueCmdI'm here now ;)20:53
olofkstupid python20:53
blueCmdyeah, it's good enough for Google - but FuseSoC is soo complex :P20:54
olofkYeah. It's so complex that it totally needs multiple inheritance20:54
* blueCmd sighs20:55
blueCmdanyway, my work on fusesoc is kind of blocked on that we get stuff like this sorted - I want to know how to design stuff I implement20:56
blueCmdhow to implement stuff I design*20:56
blueCmdlong day20:56
olofkYes. I get that.20:56
olofkI'm cool with moving section/ to section.py20:57
olofkAnd I'm cool with removing the Provider base class even though I think it's a fucking unnecessary thing to do20:58
blueCmdhaha. I think it's a fucking unnecessary thing to have :)20:58
olofkand next time someone wants to add another section, it definitely has to be split up into multiple files (preferrably in sections/$subsection.py20:59
stekernsnoop dawg....20:59
olofkand simulator, build and provider should get the same treatment20:59
stekernthis is a f*cking mess20:59
olofkblueCmd: But make sure to keep stuff python3 compatible as well21:00
olofkoh well. Good night21:00
blueCmdolofk: it's hard without testsuites, but I'll try21:01
blueCmdolofk: what was the name of that python lib that you wanted to use for gui editing?21:07
blueCmdmaybe we can just use javascript:
blueCmdor just graphviz21:29
blueCmdstekern: olofk: do we want a .config / menuconfig interface for fusesoc?21:43
blueCmdto generate stuff like uart_defines, or1200_defines and orpsoc-defines21:44
blueCmddo 'fusesoc menuconfig' to get a nice interface or something21:44
blueCmdor maybe it's just easier to have ppl fork systems-dirs and change the .core and .system file21:48
blueCmdyeah, stupid idea21:48
stekernfinally... something that remotely works...22:31
stekernbetter go sleep while before I notice that something is still broken ;)22:33
blueCmdlet me know when you got it working locally as well22:34
blueCmdsince it's quite late for poor stekern22:35
blueCmdaah you got it!22:35
blueCmdbravo :)22:35
stekerntoo tired... need... sleep... ;)22:35
blueCmdgood night :)22:36
--- Log closed Wed May 28 00:00:08 2014

Generated by 2.15.2 by Marius Gedminas - find it at!