alerante has quit [Remote host closed the connection]
whee has quit [*.net *.split]
whee has joined #nanoc
whee has quit [*.net *.split]
whee has joined #nanoc
zen79 has joined #nanoc
zen79 is now known as fritz79
fritz79 has quit [Quit: fritz79]
fritz79 has joined #nanoc
fritz79 has left #nanoc [#nanoc]
fritz79 has joined #nanoc
fritz79 has left #nanoc [#nanoc]
fritz79_ has joined #nanoc
fritz79_ has quit [Quit: fritz79_]
fritz79 has joined #nanoc
fritz79 has quit [Quit: fritz79]
<musicmatze>
Hi there. I'm currently working on the kernel of my static site compiler. Maybe two to four weeks until it is ready! This means I can start writing the loader moduke, compiler module and builder module and then I can start testing and debugging! Just if someone is interested in this...
<ddfreyne>
musicmatze: Neat :)
<ddfreyne>
musicmatze: Is it the C one?
<musicmatze>
Yes it is.
<musicmatze>
I'm looking forward for the error output of the compiler.
<musicmatze>
four weeks until the code is ready, maybe. But then another week or two until all compiler errors are fixed. ^^
<musicmatze>
I think I will write dummy-modules when the kernel is ready, to be able to test it.
<musicmatze>
No multi-threading atm, btw!
<ddfreyne>
musicmatze: How are you handling the rules?
<ddfreyne>
Custom DSL? integrated scripting language like lua?
<musicmatze>
Currently, I don't think about them. This will be part of the config parser module. The kernel asks the config parser for several things: "Should I pass this data node to this module, is this data node related to that one?" and so on. The config parser module has to parse the config file on its own.
<musicmatze>
This can be whatever you like! Lua, DSL, JSON, foobar!
<musicmatze>
I don't know yet!
<musicmatze>
That's the idea of the modularity. I'm able to adapt another config parser module if I want! Compiler my side with the one compiler backend the first time, but then take another if I want to.
<musicmatze>
The kernel has a minimal config parser included (iniparser c library) to be able to locate the module-files (.so libs) and some basic configuration, but then the config parser module has to parse the "real" config file.
<musicmatze>
(currently just on the config branch and on the config_arguments branch).
<ddfreyne>
musicmatze: Ahh, nice. nanoc 4.0 has a configurable rules store as well, so I could probably build a nanoc where rules are defined in a custom DSL
<ddfreyne>
I am making massive changes to the nanoc codebase
<musicmatze>
That's nice. I'm thinking about writing the rules-parser in ruby. That's another idea of the modularity: I want to be able to integrate other languages. For example: I like erb. I want to be able to write a templater-module with erb as backend. Or even python, Go or whateveryoulike!
<ddfreyne>
Yep
<musicmatze>
Wow! That's a lot. And I can see: you still like deleting code! :-P
<ddfreyne>
musicmatze: The rules store in nanoc is not what I want it to be yet. It needs to be an "execution engine" instead of delivering rules to execute. The DSL, Rule, RuleMemoryStore, ... should all go into a separate module
<musicmatze>
That's it.
<musicmatze>
Do you want to outsource it to a seperate gem?
<musicmatze>
The logic, not the interface... :P
<musicmatze>
because then, I could write a C-to-Ruby interface to use it! :-P
<ddfreyne>
musicmatze: I'd like to get it to a point where it is *easy* to put it into a separate gem. Everything, in fact... I could have a nanoc-datasource-filesystem gem, a nanoc-filter-erb gem, a nanoc-exec-rules gem, ...
<musicmatze>
nice!
<ddfreyne>
Even the way item reps are written is modular now. THe default implementation ("filesystem") writes to disk, but you could also directly upload it, or write it to a database, ...
<ddfreyne>
class ActiveRecordItemRepWriter < Nanoc::ItemRepWriter
<musicmatze>
Sometimes I think, I can never be involved in such a big project, because my knowledge is to small about the theory behind it. I have to rewrite almost everything to get an idea how things work.
<ddfreyne>
The idea that drove me to this separation is to think of objects as having a certain role: some objects are entities, such as items and reps, while others are stores (item rep writer, rules loader, various caches), and others are controllers (compiler, outdatedness checker)
<musicmatze>
maybe that will get a problem some day. :-|
<ddfreyne>
So I will have lib/nanoc/base/entities, lib/nanoc/base/stores, ...
<ddfreyne>
nanoc 4.0's tests are of fairly low quality because I am not actively maintaining them properly. I'm changing too much stuff, playing, experimenting. You could say that I'm prototyping. Once I have a good feeling of what certain objects should be like, I'll probably rewrite the prototypes in a TDD way.
<ddfreyne>
Alright, merged the feature-merged-rules branch
<musicmatze>
:D That's what I do: Write the logic, prototyping. Not even thoughed one time about which testing framework I will use!
<musicmatze>
thought*
<musicmatze>
So... I'm going for having lunch now!
<musicmatze>
cu!
<ddfreyne>
Seeya!
<ddfreyne>
CodeClimate says only Nanoc::Compiler and Nanoc::ItemRep are pretty bad now. F and D, respectively. The rest is C or better
koan_ is now known as koan
alerante has joined #nanoc
<musicmatze>
Wooooohoooa! First module-executing algorithm added :-P 7 more to go...
<musicmatze>
Fuckfuckfuck. Just did a git reset --hard on changes I wanted to keep!!! AAAAAH FUUUUCK!
<musicmatze>
3 hours work LOST!
<musicmatze>
wait a sec. I think I'm wrong.
<musicmatze>
I don't know anymore if there were changes or not... I should do something else.
<musicmatze>
Bad shit.
<musicmatze>
Puh. Finally pushed. So I cannot destroy things anymore. :-P
VitamineD has joined #nanoc
cDlm has quit [Ping timeout: 256 seconds]
VitamineD is now known as cDlm
fritz79 has joined #nanoc
louquillio has quit [Remote host closed the connection]