jlanda has quit [Quit: No Ping reply in 180 seconds.]
dissonant_ is now known as dissonant
jlanda has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
danitool has joined #openwrt-devel
danitool has quit [Client Quit]
ynezz has quit [Ping timeout: 256 seconds]
ynezz has joined #openwrt-devel
hbug___ has joined #openwrt-devel
hbug__ has quit [Ping timeout: 240 seconds]
_whitelogger has joined #openwrt-devel
SergioCabral has quit [Quit: I left, Guys. To send a hello chat@sergiocabral.com]
Nick_Lowe has joined #openwrt-devel
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
Nick_Lowe has joined #openwrt-devel
Darkmatter66_ has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Darkmatter66 has quit [Ping timeout: 240 seconds]
Nick_Lowe has joined #openwrt-devel
zkrx has quit [Ping timeout: 240 seconds]
zkrx has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zjason has joined #openwrt-devel
Dracos-Carazza has joined #openwrt-devel
Dracos-Carazza_ has quit [Ping timeout: 256 seconds]
_whitelogger has joined #openwrt-devel
<hurricos>
I'm working on the P2041RDB and I used 5de6aed42c (mpc85xx: add support for Freescale (NXP) P2020RDB) as a starting point
<hurricos>
but sadly I'm getting a machine check exception when attempting to u-boot the initramfs that results.
<hurricos>
and I don't know how to read powerpc assembly :)
<hurricos>
or, well. No. PowerPC machine code :(
<Tusker>
hurricos: I've attempted to get something running on a P1020 based Aerohive AP370, and it runs fine, but sysupgrade is having issues with nand bad blocks offsets...
<Tusker>
do you have a pastebin of what you are seeing ?
<hurricos>
Isn't the AP370 basically a souped up AP330?
<Tusker>
yeah, pretty much, I've managed to fry one though and doesn't even get to u-boot anymore... not sure what is going on with the boot process, so will need to JTAG once I have some time
<mangix>
blocktrron: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=blobdiff;f=tools/zstd/Makefile;h=f474cb856460c19ed05cb5d947768008eed22db0;hp=7459725e8e79b846ed96551753d07fdd02459598;hb=c261a066f15e5399ee318e5eb2b98510f6e5be0d;hpb=0bcf25cf481334552edb19dbea342bce697b3850 the original URL has always been wrong. The GITHUB macro is not used correctly here.
<mangix>
well, use the gz file instead of the zstd one
<Tusker>
hurricos: have you tried loading the kernel and DTS separately ? Load Address of 0xc0000000 may not be a good choice if it relocates ?
<hurricos>
OK, got something! I tried a different memory region and got past it. It must have been because OpenWrt 32 bit PowerPC wants to limit RAM to 3GB
<hurricos>
yeah
<hurricos>
echo $((0xc0000000/2**20)) is telling
Misanthropos has quit [Ping timeout: 256 seconds]
<hurricos>
I do currently load the kernel and dts separtely. Looks like I need to hunt some bugs with the dts ...
<hurricos>
How does the AP330 get the fdt compiled?
<hurricos>
I think I need to build a separate one than the one the vendor provides.
<hurricos>
WARNING: could not find compatible node fsl-usb2-mph or fsl-usb2-dr: FDT_ERR_NOTFOUND.
<Tusker>
i took the AP330 DTS, and the factory DTS, and merged the two, based on the latest kernel
<Tusker>
that uboot looks like it should support fdt print
<Tusker>
so, ftd addr 0xc00000; ftd print should give you something to work with
<hurricos>
Oh yeah
<hurricos>
awesome
<hurricos>
alright, time to get some sleep first. but encouraging!
<Tusker>
then, look at each of the compatible lines, and see whether it still exists in 5.4.81, and modify to the newer one
<hurricos>
oh yeah the original running kernel is um
<hurricos>
3.0 :)
<Tusker>
yup, so tweaking necessary
<hurricos>
I was thinking though. This board actually comes with a dts
<hurricos>
vendor-provided
<hurricos>
In the vendor's SDK, in OpenWrt
<Tusker>
well, it's loaded in memory anyway, so you can just dump what's there, which would match the dts in the vendor SDK
<hurricos>
so basically what I'm wondering is, how do I compile that into an fdt which I can load up
<hurricos>
I think the vendor's is newer than this board is
<Tusker>
ah ok
<hurricos>
like significantly
<hurricos>
this was built in .... 2012
<hurricos>
:(
<Tusker>
if you want to do it properly, you can use my aerohive ap370 PR as a basis to get the build building the necessary stuff
<Tusker>
otherwise, you can manually compile the DTB with dtc -I dts -O dtb ...
<hurricos>
man am I glad this board has 1Gb SPI NOR :)
<hurricos>
and not NAND LOL
<hurricos>
best of luck, thanks for the help @tusker!
<Tusker>
no worries :)
Misanthropos has joined #openwrt-devel
falk0n_ has quit [Ping timeout: 256 seconds]
Grommish has joined #openwrt-devel
black_ant has quit [Ping timeout: 240 seconds]
dedeckeh has joined #openwrt-devel
falk0n has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
Darkmatter66_ has quit [Ping timeout: 264 seconds]
damex has quit [Ping timeout: 240 seconds]
<Grommish>
Whose up that and has an opinion on how packages or software in general should behave. Bonus points if the opinion fits into the OpenWrt framework, but I'll take the under if I have to
<PaulFertser>
rsalvaterra: for the reference, the Intel devs usually monitor the kernel bugzilla and ucode crashes are eventually fixed when reported there. It just takes loooong time
javi404 has quit [Quit: javi404]
<rsalvaterra>
Wow, someone's actually looking at the kernel bugzilla…? O_o
<rsalvaterra>
My experience is that bugs just die of old age there…
<mangix>
rsalvaterra: intel listens
javi404 has joined #openwrt-devel
<mangix>
qualcomm does not
<rsalvaterra>
Oh, well… I just mailed Luca Coelho and Johannes Berg directly…
<mangix>
t
<mangix>
I remember correspondance with the former
<jow>
I thought this is expected. But I lost track of the 64k sector thing
<jow>
as long as this is a one-time transition thing I'd consider it a wontfix
<jow>
same as non-DSA to DSA migration
<jow>
especially since we're not talking about bricks but about losing settings, so it is acceptable imho
MarioH has joined #openwrt-devel
voxadam has quit [Ping timeout: 246 seconds]
voxadam has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 240 seconds]
damex has joined #openwrt-devel
<adrianschmutzler>
jow: well, that 4k sector problem will essentially affect all mikrotik devices
<adrianschmutzler>
so, they won't be much fun to use now
Nick_Low_ has joined #openwrt-devel
damex has quit [Client Quit]
Nick_Lo__ has joined #openwrt-devel
damex has joined #openwrt-devel
<adrianschmutzler>
but this discussion is going on for half a year now at least, and despite john-tho's attempts to fix the issue, it doesn't seem like anybody from the maintainer side is interested (even upstream, if I remember correctly - nobody even answered on his patch there)
danitool has joined #openwrt-devel
voxadam has quit [Read error: Connection reset by peer]
Nick_Lowe has quit [Ping timeout: 272 seconds]
Nick_Low_ has quit [Ping timeout: 272 seconds]
voxadam has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
Nick_Lo__ has quit [Ping timeout: 272 seconds]
<damex>
does the 4k problem affect nor or nand flash?
<adrianschmutzler>
in that case, nor
Nick_Lowe has joined #openwrt-devel
damex has quit [Read error: Connection reset by peer]
dangole has quit [Remote host closed the connection]
damex has joined #openwrt-devel
dangole has joined #openwrt-devel
muhaha has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
<barhom>
How are hotplug.d/neigh triggered? I thought it would be triggered by maybe when the kernel adds something to "ip -4 neigh". But it doesn'
feriman has quit [Ping timeout: 258 seconds]
feriman has joined #openwrt-devel
<Tapper>
Hi people is OpenWrt 19.07.5 ready?
<Tapper>
There has bin no email about it but there is a post in the forums.
<Tapper>
and what about 18.06.9
<Tapper>
Should i post about it on the openwrt twitter or what?
finsternis has quit [Ping timeout: 240 seconds]
finsternis has joined #openwrt-devel
<zorun>
Tapper: it's not ready, do you have a link to the post?
gch981213886000 has quit [Quit: Ping timeout (120 seconds)]
gch981213886000 has joined #openwrt-devel
valku has joined #openwrt-devel
KGB-0 has quit [Quit: KGB-0]
KGB-0 has joined #openwrt-devel
KGB-0 has quit [Quit: KGB-0]
KGB-0 has joined #openwrt-devel
goliath has joined #openwrt-devel
<rr123>
jow: is https://openwrt.org/docs/techref/luci2 still relevant/updated for the new luci you're working on? any doc about the new luci in master branch other than the client-js-api pages?
<ldir->
only on the condition that cockstrap is also nominated
* dorf
lols
<rr123>
currently new luci will poll constantly, chrome devtools xhr will be flooded by them, what about doing the xhr with websockets instead of ajax calls
<rr123>
i have no idea how websockets calls will be authenticated though
<ldir->
whilst I'm all for puerile schoolboy humour I also think that we shouldn't discourage women from our ranks
<Tapper>
Hi can some one give me the Logo URL for OpenWrt?
<dorf>
ldir-: absolutely. apologies if my inane comment caused any offense.
* rr123
feels europe has already been managed by ladies in the government, usa is catching up
<Tapper>
rr123 good
<dorf>
rr123: if web sockets make less demands of the browser, I'm all for them.
<dorf>
there are places where ajax can effectively hang the browser, specifically the realtime graphs -> connections page.
<Tapper>
I am going to set up a OpenWrt folding at home team.
<ldir->
no no, not at all - it just got me thinking - openwrt strikes me as a very male 'hobby'.
<Tapper>
ldir Yeah
<Tapper>
ldir I like to see a female name around the place. If I ever do spot one I never say anything tho just incase I am rong.
dorf is now known as dorfetta
<rr123>
dorf: i began to study websocket yesterday, i feel the new luci is still luggish a bit sometimes, offload cpu from the target did not help a lot, so it could be related to design, embedded board sometimes run long-time calls which incur polls, websocket can help there
dorfetta is now known as dorf
<Tapper>
ldir and it's mad even when gamming or posting on a from if you use a girls name you get tretted difrent.
<rr123>
s/luggish/sluggish/
<Tapper>
gaming* Different*
<dorf>
rr123: yeah, I hear you. I'm not entirely convinced ajax is the way to , either, or indeed handing everything off to javascript, but I'm not the one making the call.
<Tapper>
treated* forums*
<dorf>
Seems to me there's plenty of content in LuCI that could just as well be rendered statically with no real penalty.
dangole has quit [Ping timeout: 240 seconds]
<rr123>
dorf: agree, lots of room to improve on webui, an updated design doc will help :)
<dorf>
rr123: I've been working with ajax lately in another project. If you use it selectively, it's pretty low-footprint.
<dorf>
I redid all the "refresh the entire page every x seconds" routines to "refresh this specific div only if something changes".
<rr123>
dorf: for CRUD database driven restful backend i would expect ajax will do well, for cgi-jsonrpc backend, some ajax could essentially 'block', or incurs lots of polls, it might not be the best option
<rr123>
isn't ajax's goal not to refresh/reload the page from the start
<dorf>
sure, no argument there. just open the connections graph with a few thousand connections..
<rr123>
you got a json, and update that div
<dorf>
not only will the ajax hang the browser, it'll also take down luci :)
Acinonyx_ has quit [Ping timeout: 260 seconds]
Acinonyx has joined #openwrt-devel
<jow>
rr123: no it is not
<jow>
luci2 was a tech demo to demonstrate the viability of exposing ubus via http
<rr123>
that page was updated 2020.09 so i thought it is still relevant, thanks for clarifying
<jow>
that has been backported to luci(1) which is slowly migrating from server-side rendered content to client side rendered views which fetch relevant data via ubus-rpc over http
<jow>
sometime in 2021 I plan to drop the last server side Lua bits
<jow>
at least for the default install
<rr123>
an update to the new architecture will be nice, i might be able to help testing or contribute if I can figure out how
<jow>
its all in master
<jow>
and it already is using the new architecture
<dorf>
is there a pain free way to update to master without having to reinstall and reconfigure everything?
<jow>
run it in Qemu
<jow>
thats what I do most of the time for development
<dorf>
right, so not a good idea on a working router then.. yeah, I've got a vbox install for that.
<jow>
some classes are undocumented yet, e.g. validation.js
<jow>
will hopefully get around to that eventually
<rr123>
is it feasible to add a websocket proxy to uhttpd so for certain pages(e.g. graph) we can use websockets instead of ajax for page update?
* karlp
giggles
<jow>
there's non non-crappy, non-bloated implementations are available
<jow>
so feasible yes, but the footprint will easily double the entire luci storage footprint
<karlp>
weren't you saying that you didn't see any perf improvement of js over lua the other day? now yoiu want to websockets it to skip ajax?
<karlp>
or am I mixing you up with someone else?
<rr123>
iopsys's owsd and orangerpcd are both new to me, will study their code, seems interesting, but this frontend thing is still very new to me
<jow>
I have been told that the iopsis juci gui does not even compile anymore nowadays because all the nodejs dependencies became incompatible in the meanwhile
<jow>
orangerpcd is a fork of rpcd with Lua scripting support
<jow>
or at least it was, last time I looked at it
<rr123>
karlp: it's me, but i'm confused in this field and still learning, will do the ajax way as usual while trying websockets on the side
<karlp>
I use mqtt over websockets in for openwrt uis a lot in our stuff, but it depends entirely on what's making the data
<karlp>
ajax or websockets don't really hcange that much
<rr123>
jow: i think iopsys "abandoned" juci to some extent and use their own stuff for ui now, juci project essentially stopped evolving since 4 years ago
<jow>
rr123: which has been my experience with any "lets make a new luci with modern web technology" over the last twelve years
<rr123>
:)
<jow>
people soon get so much entangled in chasing the latest framework that the projects never make it out of the proof-of-concept stage and reach feature parity
<jow>
they usually come with a nice, fancy looking dashboard and some minimal configuration capabilities while not implementing the entire long-tail
<rr123>
true, especially on the frontend, which is insane still
<dorf>
In essence, the difference between websockets and ajax is that sockets are push, and ajax is pull, no?
dangole has joined #openwrt-devel
<rr123>
dorf: interesting to read but no surprise, latency of course matters, for board like openwrt/luci, most of the time it's local access so certain ajax call will overshadow the latency time
<dorf>
yeah, that's my thinking, rr123. mostly access will be over a lan.
<rr123>
is it worth the complexity to add websockets to luci, I know too little to say, but will keep playing with the idea as a learning process
<dorf>
I'm just wondering if I can transition some of my ajax stuff to websockets without too much hassle.
<rr123>
dorf: same here, so far I don't know how to 'secure' the wss calls, i.e. how to authenticate wss
<dorf>
well, wss _is_ secure, no?
<dorf>
it's encrytped, at least.
<rr123>
openwrt needs to get some token for the session and use it on wss, ws has no cross-origin protection either
<rr123>
wss is secure as https, but it's different from authentication, e.g. you need logged in to use the wss/ws
<dorf>
Sec-WebSocket-Key and Sec-WebSocket-Accept should handle authentication.
<Grommish>
Does anyone know how to pull a target's triple? (eg: mip64-openwrt-muslabi64) Is there a $() for it?
<Grommish>
I was looking in ./include instead of the rules.mk where it was kept :)
<adrianschmutzler>
jow: how stable is the current luci in master btw? are there any blockers apart from dsa support?
<rr123>
dorf: socket.io must have solved this authentication issue long time ago, the problem is how to do something similar in openwrt, if possible
<Grommish>
adrianschmutzler: I need your opinion on something, when you get time
<adrianschmutzler>
Grommish: if it doesn't take too long, you can shoot
<dorf>
rr123: first you need to persuade jow websockets is a good idea :)
<rr123>
dorf: i need learn more to convince myself first :)
<dorf>
that too :)
<Grommish>
adrianschmutzler: Rustlang.. It uses predefine triples for the targets. These are not consistent with the OpenWrt triple convention. Do you recommend 1) morphing the Openwrt triple to match the existing Rustlang triples, or 2) replace the stock rust triples with full custom ones that will match the naming convention
<Grommish>
adrianschmutzler: example: mips64-unknown-linux-muslabi64 is what rust calls it.. Openwrt's build system calls it mips64-openwrt-linux
<rr123>
Grommish: are you trying to get rust into openwrt? I cross-compiled a rust small program and run it on mips-openwrt and it worked fine
<Grommish>
this is a pendantic, nit picky issue and I'm request you help me figure out the best way to do it :) Not code wise, just overview wise
<Grommish>
rr123: I've already done it, I just need to finalize the stuff
<rr123>
cool
<Grommish>
One of the issues I'm having is the triple naming convention.. and if I have to change one (and I do for mips64, which is soft-float and dynamically linked)
<Grommish>
I might as well change them all
<adrianschmutzler>
Grommish: sorry, don't even really understand the question.
<adrianschmutzler>
That touches too much stuff I'm not familiar with
<Grommish>
adrianschmutzler: Should I make OpenWrt work with stock rust naming conventions, or change rust to match Openwrt's
<Grommish>
is the gist of the question
<Grommish>
either way is about the same amount of work and the no user will ever see it
<Grommish>
it's all internal to the build system
<Grommish>
but, I figure someoen will have an opinion one way or another on how it should be
<adrianschmutzler>
I don't have any knowledge of rust and this is too far down in the building system for me to judge
<Grommish>
and I respect your opinion on it
<rr123>
also played with golang cross compile, then threw it away, 1. binary size is too big(have not tried shared build which is available) 2. upx compressed go binary will take lots of cpu cycles to decompress 3, this one kills it, a small go binary will ask for like 300MB or 600MB VSS, i know it's not RSS, but still, 600MB VSS on 64MB RAM openwrt is too much for me to continue
<adrianschmutzler>
so I cannot give an opinion, sorry
<Grommish>
adrianschmutzler: thank you :)
<Grommish>
rr123: I cross compile fine. I have Suricata6.0.0-beta1 working
<Grommish>
rr123: Also, I'm not putting rustc/cargo on the device at this time.. it is only for host right now
<Grommish>
rr123: for cross-compiling
<Grommish>
but the triples are causing issues, so.. I figured I'd either "fix" them, or scrap them and make new ones as a patch
<rr123>
yes cargo on openwrt board(unless it's x86) is going to take hours to build a new release of any rust program
<Grommish>
No
<Grommish>
I create an installation binary tarball after the first build
<rr123>
how, it took minutes on my 8-core 16GB x86 desktop
<Grommish>
and call it from Host/InstallDev
<Grommish>
the FIRST compilation will take a bit, yes
<Grommish>
After that, unless the package is changed, it'll just use the installation tarball to install the already compiled 9and stored) installation files
dangole has quit [Remote host closed the connection]
<Grommish>
455079748 Nov 16 05:53 dl/rust-1.49.0-x86_64-unknown-linux-gnu_mips64-unknown-linux-muslabi64sf-install.tar.xz
dangole has joined #openwrt-devel
<Grommish>
Granted, I am building the ENTIRE 3-stage bootloader and ALL of the tools
<Grommish>
So the installation tarball is huge, but I will eventually par that down since it includes both the host and the target toolchains
<rr123>
looking forward to rust on openwrt :) even though I'm still everything-in-C
<Grommish>
I am actively looking for people to help test it.. because each triple will need to be mapped one way or the other
<Grommish>
I've got the rust package and a Suricata6 package to test it with
<Grommish>
if you get bored enough to try it out, hit me up :)
<rr123>
suricata is writting in rust?
<rr123>
written
<Grommish>
rr123: requires rust/cargo as of Suricata5, yes
<Grommish>
it's the reason I started with rust, because someone wanted suricata
<Grommish>
*shrug*
* rr123
feels the fad is now indeed, re-write everything in rust, i.e. make other code rusty, literally.
<Grommish>
hehe I'm not a programmer, so rust vs C++ vs whatever doesn't mean much to me
<Grommish>
but the rust proponents seems to laud it
<adrianschmutzler>
Grommish: btw: I typically don't do packages at all; so, I do not really now the standards that are applied in the packages repo anyway
<adrianschmutzler>
now -> know
<Grommish>
adrianschmutzler: I know, but you are a reasonable fanatic for common sense standards, so i figured I'd get your opinion on it :)
<jow>
rr123: ES5 so far, I tried to be very conservative
<adrianschmutzler>
Grommish: but I can't play in every game, so I normally ignore packages repo entirely
<dorf>
jow: have you thought about selective refresh with ajax, only updating changed components? looks like currently you're pulling the entire view div?
<jow>
rr123: but some arrow function crept in with a recent PR and IE compat is not a thing anymore anyway
<dorf>
on that we can agree, but that ship has sailed.
<karlp>
99% of the world's browsers doesn't always mean 99% of a given market's users IME, but *shrugs*
<karlp>
which ship?
<dorf>
the one that uses js to render html.
<karlp>
well, can we fix it?! we had a perfectly reasonable html+css, and js for dynamicness
<karlp>
why do we now have to throw out html and create it
<karlp>
it's hideously hard to work with
<dorf>
it is a pain, I agree. Maybe I'm old school, but give me static html and scripts where required any day of the week.
<karlp>
it would be my vote for "things to spend modern web dev time on" rather than getting excited about ajax vs serrver sent events vs websockets vs whatever else
<karlp>
I use knockout+js templated by lua views a lot traditionally in openwrt
<karlp>
the lua view is mostly just tellin luci the thml, and setting some js vars with the media roots, and some url paths
<dorf>
yeah, but wasn't lua the problem that ajax is trying to address?
<karlp>
not entirely,
<karlp>
ltos fo lua views were heavily doing lua scripting _in the view_ before it was rendered to the client
<karlp>
if you jhust have luci dispatch the html+js, and provide some url paths to ubus and json-rpc, you still get snappy client stuff
<dorf>
in that case, why bother with lua at all? just build the pages in html and add the js where required?
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dorf>
and presumably if there's dynamic content that requred reading from ubus, lua can handle that?
<dorf>
I guess it's not so different to java/jsp being rendered to html, which is what I'm most familiar with.
Darkmatter66_ has joined #openwrt-devel
<dorf>
jsp handles static html (mostly), and java fills in the dynamic content, and javascript provides the icing where required.
Darkmatter66 has quit [Ping timeout: 265 seconds]
<rr123>
ES6 is old, heard about ES12? :)
<rr123>
openwrt is always taking the bleeding edge anyways(e.g. kernel version), back compatiblity was not the most important thing i feel, so newer js esp ES6 is fine i hope
<Tapper>
rr123
<Tapper>
dorf: If you need to make changes to LUCI that needs more libs installed on the router you are going to get told no pretty quick. Space is a massive thing on inopenwrt
<Tapper>
on OpenWrt*
<Tapper>
I am not a dev, but have seen a lot of things shot down because they take up to mutch space!
* rr123
feels minified js/css should stay below 500KB, a quick look at /www I have 1.3MB(un-minified), maybe in the future webpack/tree-shaking/whatever can be introduced to produce compact frontend chunks to further reduce the size
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
feriman has quit [Quit: WeeChat 3.0]
feriman has joined #openwrt-devel
Darkmatter66_ has quit [Ping timeout: 240 seconds]
<dorf>
the point really is generating the templates and table content.
<jow>
Developing templates partials outside the target environment does not really work either
<dorf>
doing that statically is a lot easier than doing it via the powers of js.
<jow>
so what is the probkem with doing it statically and copying the resulting markup between `...` ?
<jow>
if you insist on that development workflow you will need to "port" your markup to the actual target env enventually
<jow>
cut your page template into partials, replace stuff with includes, static data with interpolations and so on
<dorf>
I'm not insisting on anything, I'm just saying, some workflows are a lot more fluid. I work with whatever's put in front of me, once I get my head around it.
<dorf>
However, as a general observation, the current model for generating templates in luci is a barrier to entry that probably puts a bunch of people off contributing..
<jow>
maybe, but that applies to any sufficiently complex system
gch9812138860000 has quit [Ping timeout: 260 seconds]
<dorf>
sure, that's not a bad point, but the question is, is the added complexity actually beneficial?
<jow>
so far you didn't propose any less complex solution
<dorf>
the less complex solution would be static html (with templated, cut and paste components) + javascript including ajax to handle the dynamic stuff.
<karlp>
I don't have one either, I just suggested that if someone wants to spin wheels, that area might be nicer than just throwing websockets at it :)
<jow>
dorf: that's what luci came from, and it was extrmely complex (and slow)
<jow>
server side rendering on weak MIPS cores is *slow*
<jow>
the current goal is the eventually get rid of any server side interpreter for generating page markup
<dorf>
yeah, that's kinda different.
<jow>
there'll be just static HTML, JS and CSS artifacts + an ubus HTTP gateway
<dorf>
the server side interpreter is probably where the slow is.
<dorf>
(not the rendering of static html)
<jow>
but I actually fial to see the problem. Nothing is stopping you from either using a custom view.htm or from fetch markup via XHR and dropping it into the DOM
<dorf>
what you're proposing sounds good, I'd just propose moving the render all the markup via js to pre-formed static html.
<jow>
how to handle things like conditional sections, loops, translation strings?
<jow>
reinvent handlebars.js?
<karlp>
jow | there'll be just static HTML, JS and CSS artifacts + an ubus HTTP gateway
<dorf>
dynamic stuff handled by javascript.
<karlp>
that sounds great to me, but right now, the "static html" seems to be all embedded inside js as well, as fixed constants
<karlp>
and that's just where I struggle with the authoring of it.
<dorf>
yeah, I like the sound of that. especially the static html part. much easier to work with :)
<philipp64>
anyone manage to get mDNS (Avahi) and Bonjour browsing working across multiple subnets? Especially two OpenWRT routers connected via IPsec tunnel?
<karlp>
philipp64: I can't even get it to work on wireless and wired at the same time with one router :)
<philipp64>
yow. sounds like an IGMP snooping issue? are both wireless and wired in the same bridge group?
<jow>
karlp: but what is preventing you from simply using custom .htm files?
<jow>
that part I don't understand
<karlp>
nothing really, it's what I'm mostly doing
<karlp>
but it's not how anything else is done, so it feels very left out
<karlp>
and when everything has become " a cbi" and that model puts it all in js
<karlp>
even though the "CBI" pages are now -much_ more dynamic than just "here's a uci config file presented as a form"
<jow>
it's easier to actually build the DOM from JS than fetching an HTML markup, parsing it into a DOM, locating all elements within it, attach event handlers to it and hope that the structure matches waht the code is expecting
<jow>
endless boilerplate of getElementById() / querySelectorAll()
<jow>
nad hope that noone messes up the selector attributes in the template
<dorf>
no doubt that could be improved, but hey, it works, ok :P
<jow>
I didn't mean to imply that the code is bad, just that you'll end up with a lot of additional sync effort
<dorf>
that's ok, you made me smile. :)
<jow>
handlebars.js / mustache.js would be an option
<jow>
but then you'll need "the environment" to test and render your markup
<jow>
or any kind of sandbox to provide mock data
<dorf>
that code is super inefficient, though.. I've done something similar elsewhere in v2 which just adds a "volatile" class to anything that might require a refresh. much cleaner.
<jow>
and even then you solved the initial rendering problem, not how to handle continuous data updates
<ynezz>
dangole: do you plan to push it eventually sometime soon?
<ynezz>
just seeing that issue with the valgrind
<dangole>
ynezz: was test-driving it in the past couple of days, works fine, i'll push it now
KGB-0 has quit [Ping timeout: 260 seconds]
<ynezz>
does it compile as it is?
<ynezz>
ustream-io-openssl.c:45:17: error: invalid use of incomplete typedef ‘BIO’ {aka ‘struct bio_st’}
<ynezz>
ah, that's maybe due to my -Wextra
<ynezz>
but still something fishy about that
<philipp64>
karlp: interesting discovery! (1) Avahi wants IFF_MULTICAST set, even on IPsec (XFRM) tunnel interfaces, (2) avahi-daemon.conf uses the first value it sees in the config, not the last, so you can’t have “[reflector] \n enable-reflector=no \n enable-reflector=yes \n” because only the first one gets set (cleared, really) so it needs to be fully commented out, (3) you need to turn off IPv6 if you’re not using it and (4) turn on
<philipp64>
“allow-point-to-point=yes”…
<philipp64>
as we speak, I’m synching my iPhone to a Mac mini 9 miles away…
KGB-0 has joined #openwrt-devel
CrazyLemon has quit [Ping timeout: 272 seconds]
<dorf>
jow: continuous updates are easy enough in that context. selective ajax refresh or websockets. whatever works with the least overhead.
<jow>
you can't have a few dozen independent components on the page each do their own ajax calls
<jow>
it needs to be centrally managed, also to avoid double fetching the same data
<dorf>
you have one ajax refresh that runs and checks for changed content.
<jow>
which needs a generic mechanism to tie markup nodes to data
<jow>
or you end up writing endless amounts of template specific glue and match code
<dorf>
yeah, the generic mechanism is just to tag anything that may require a refresh with a "volatile" class tag
Nick_Lowe has joined #openwrt-devel
<jow>
and a selector into the view model data
<dorf>
and then iterate through those when you refresh to see what's changed.
<jow>
and you need to introduce sequences
<jow>
fir things like lists of data
<karlp>
philipp64: hrm, I'm only using umdnsd now, as it's better integrated in procd, and it worked enough for me..
CrazyLemon has joined #openwrt-devel
<philipp64>
let me know if you get that working…
<jow>
you could do <span data-value=".view.foo.bar">...</span> or <ul><li data-foreach=".view.some_collecion" data-var="item"><span data-value="item.foo">...</span></li></ul> etc.
<jow>
that would be the angular approach
<jow>
then you need dirty tracking
<dorf>
this is the point where I defer, my js isn't that hot. :)
<jow>
it's simple on paper but the details aren't. Otherwise Angular would've been a ~200 line JS file
<jow>
anyhow, will think a bit about it. Off to be for now
<dorf>
have fun being o/
dedeckeh has quit [Remote host closed the connection]
Borromini has quit [Ping timeout: 246 seconds]
<dangole>
ynezz: you were right, it doesn't actually compile. I was testing it with mbedtls by accident and never actually compiled the openssl part before.