<OscarL>
No idea really. Maybe ask AGMS if you see him around?
<B2IA>
(UnrealNeil) I might ask Siri ;-)
<OscarL>
"Siri, can I run a muscle server on my nas?" --- "sure... hit the gym first."
<B2IA>
(UnrealNeil) oh! a rebbot is required...... back Soon!
mishima has joined #haiku
<B2IA>
(UnrealNeil) <takes a seat in the corner behind a potted palm>
mishima has quit [Ping timeout: 480 seconds]
jess has quit []
mishima has joined #haiku
<B2IA>
(AGMS) Butler message for UnrealNeil Yes, you can run a BeShare server (and bots) on Linux. Source code is part of the https://github.com/agmsmith/BeShare repository.
<B2IA>
(AGMS) That code uses the old 3.40 BeShare Muscle library, on purpose for backwards compatibility when compiling BeShare for PPC computers.
<B2IA>
(AGMS) Hi UnrealNeil, did you get the messages from Butler?
<B2IA>
(UnrealNeil) yes
<B2IA>
(UnrealNeil) one
<B2IA>
(AGMS) Should be 2, try a butler catsup 10 instead.
<B2IA>
(UnrealNeil) butler catsup 10
<B2IA>
(UnrealNeil) thanks
mishima has quit [Ping timeout: 480 seconds]
<B2IA>
(AGMS) Anyway, this Beshare server is running on Fedora Linux, recently recompiled so new new compiler quirks with GCC12.
<B2IA>
(UnrealNeil) i have an old debian, and it's argueing with me about unsafe repositorys
<B2IA>
(AGMS) Oops, "no new compiler quirks""
<B2IA>
(UnrealNeil) i'll look into it more tonight
<B2IA>
(AGMS) Have fun, I'll be away tomorrow at a big data conference at the local university.
<B2IA>
(UnrealNeil) but since it's running 24x7, i might as well set it up...
<B2IA>
(UnrealNeil) AGMS thanks very much for the link
<B2IA>
(AGMS) No problem.
<B2IA>
(AGMS) Would be nice to have an alternate BeShare server too!
<B2IA>
(UnrealNeil) ok, what do i need to read up on for that?
<B2IA>
(AGMS) Bonus points if your router can do Hairpin Routing, so you can access your server as if you were outside (otherwise other users get your internal LAN address rather than your BeShare client address when querying the server).
<B2IA>
(AGMS) There should be docs in that repository. Basically you run muscled with some command line argments and config files, and then run Atrus or whatever the bot is called.
<B2IA>
(UnrealNeil) ahhhh maybe more apt for my sons server setup
<B2IA>
(UnrealNeil) ok. i'll look into it
<B2IA>
(AGMS) Just means that without Hairpin, people can't download files from your BeShare.
<B2IA>
(AGMS) Though you could just log into my BeShare and then other people will see your external IP address and be able to download (if your firewall is open for BeShare file sharing).
<B2IA>
(AGMS) Anyway, that's what I have set up for the #Haiku BeShare client user, which shares files and copies text to IRC.
<B2IA>
(UnrealNeil) ok, thanks
<jessicah>
beshare file sharing back in the day was pretty epic
<B2IA>
(AGMS) Must have been a lot of people who knew how to forward ports in their router.
mishima has joined #haiku
<jessicah>
hmm, pretty sure beshare handled traversal pretty well
<jessicah>
but it was a long, long time ago
<B2IA>
(AGMS) It couldn't handle routing if both ends of a file transfer were firewalled.
<jessicah>
and jealous of people with their dual cpu systems :p
<B2IA>
(AGMS) So if you were sharing files, it was best to forward the BeShare file sharing ports, 7000-7009 (or more for however many simultanous connecitions you were expecting).
<zdykstra>
Dual P2-350, awww yeah
<zdykstra>
That thing was the bees knees
<B2IA>
(AGMS) Yup, dual P3/550Mhz Pentiums here. Big slot cartridges with built in fans, now failing, so I don't run it much.
<OscarL>
reading the IRC logs... I see that BrunoSpr managed to hit what I suspected could happen with the AboutSystem replicant, sigh. (https://review.haiku-os.org/c/haiku/+/6158, first comment).
<B2IA>
(AGMS) I'm surprised how zippy my laptop from last year is.
<zdykstra>
I upgraded to P3s of some kind when there was a fire sale on them. That system is long gone, though :(
<OscarL>
way to trigger that bug? Add a AboutSystem replicant to desktop, change your CPU, then update your Haiku install :-D
<zdykstra>
lol
<zdykstra>
Back in the day of slot mount CPUs, that'd be easy!
<OscarL>
or just moving your HDD/USB-drive to another PC, I guess
<OscarL>
Any way.... Adding that to my ToDo list. At least I know how to fix that one :-D
<zdykstra>
Pff, don't be practical
mishima has quit [Ping timeout: 480 seconds]
AlienSoldier has joined #haiku
<jessicah>
ah yeah, I hate a slot mount P3-600
<jessicah>
had*
<jessicah>
they've kind of made a comeback of sorts with the nuc compute element
<B2IA>
(AGMS) Also annoying people with dual P3-800 systems. Oh well, at least mine had error correcting memory.
mishima has joined #haiku
<B2IA>
(AGMS) Anyway, that Pentium series (PII the first really) let you view JPEGs quickly. Then the Core 2 let you do video. Intel generation 12 lets you do what? Hmmm, maybe running AI is the next benchmark.
<B2IA>
(AGMS) Anyway, bedtime, got a day of head spinning lectures tomorrow on big data. I'm sure someone will mention AI there too.
<AlienSoldier>
Well video can still be compressed a lot i think if more cpu is available
<AlienSoldier>
not something completely new that said
mishima has quit [Ping timeout: 480 seconds]
<Skipp_OSX>
AVX512, VMX
mishima has joined #haiku
<Skipp_OSX>
let's you do vm's quickly basically
HaikuUser has joined #haiku
mishima has quit [Ping timeout: 480 seconds]
HaikuUser has quit []
<B2IA>
(UnrealNeil) butler catsup 100
<AlienSoldier>
OscarL blockout is quite nice. full screen in 16x9 screen is a bit anoying because the askpect ratio resolution are only 4:3 so it is stretched. Also it crash on exit here. It also weirdly never appear in my "recent application" directory after i run it. It would also need an icon (hopefully with the hand from the coverart of the original hand on the current binary 3 block haiku icon)
<OscarL>
AlienSoldier: it not appearing on your recent list is due it missing .rsrc (with App flags/icon/version) I think.
<B2IA>
(UnrealNeil) butler catsup 50
<OscarL>
Should be an easy fix if that's the case. We need someone to draw an icon for it thou :-D
<AlienSoldier>
OscarL now i feel challenged to rank #1 on the online score :P
<OscarL>
:-D
<OscarL>
bbiaw.
mishima has joined #haiku
<B2IA>
(UnrealNeil) <suspect>
mishima has quit [Ping timeout: 480 seconds]
<AlienSoldier>
comparing pc version and amiga one, the amiga one is better. Copper list depth effect and a better selection for different height level.
<AlienSoldier>
UI is also better, so is the title screen and music
<AlienSoldier>
the remake is definitively based on the PC version
mishima has joined #haiku
<AlienSoldier>
genesis one seem the worst
mishima has quit [Ping timeout: 480 seconds]
Maturi0n_ has joined #haiku
<AlienSoldier>
ho, arcade one have 2 player simultaneous option
smalltalkman has joined #haiku
<AlienSoldier>
I think that game could be done quite well on vectrex
<moparisthebest>
Does anyone use rust much on haiku ? Like can I do something to make libc compile?
<waddlesplash>
nielx[m] is the one who maintains the rust port, and I know kallisti5[m] is also a rust programmer
<moparisthebest>
It fails to link because -lunix can't be found
<waddlesplash>
we don't have any such thing as "-lunix" so I'm not sure why it would try to link against that
<moparisthebest>
Right
<waddlesplash>
the system C/POSIX library is "libroot"
<waddlesplash>
with network-related (socket, etc.) functions in libnetwork
xet7 has quit [Ping timeout: 480 seconds]
<waddlesplash>
moparisthebest: pretty sure the "libc" crate has haiku support
<moparisthebest>
Yea there are some binary rust crates in the package repo but "cargo install" failed to compile them, hence my question
<waddlesplash>
looks like that PR was just last month
<waddlesplash>
so this has not been broken for very long
mishima has quit [Ping timeout: 480 seconds]
<moparisthebest>
I want to mention, I've been using Linux for... 18 years now? And I'm very impressed with haiku
mmu_man has quit [Ping timeout: 480 seconds]
<OscarL>
SuSE 5.1 in 1998... trying to test that "linux thing" without borking my father's PC... oh the memories.
<waddlesplash>
moparisthebest: :)
mishima has joined #haiku
mishima has quit [Ping timeout: 480 seconds]
Disreali has joined #haiku
Disreali has quit []
<OscarL>
removing a big "work-" dir under haikuporter (for lapack in this case) seems to take as long as actually build the package :-D
<OscarL>
(exaggerating, of course... mmm maybe not *that* much)
mishima has joined #haiku
<waddlesplash>
condvars post just crossed 100 points on HN, and it still has 0 comments
<waddlesplash>
I wonder how often this happens?!
<OscarL>
everytime the topic at hand makes people upvote it while not actually being smart to critique it :-P
<waddlesplash>
but HN commenters *love* to talk about things they doesn't understand :-p
<OscarL>
I may be confusing it with reddit thou
<OscarL>
:D
<waddlesplash>
or, if they really don't understand it, accuse it of being a poor explanation
mishima has quit [Ping timeout: 480 seconds]
<OscarL>
I'm with nipos (over the forum) here... even if I can't say understand it all, it is damn good to have such articles.
* OscarL
gets back to read the rest of it :-D
<waddlesplash>
well, part of the idea was to make it comprehensible to the "average programmer"
<waddlesplash>
if you can understand locks/semaphores, and atomic operations, then the idea was this should be comprehensible to you
<B2IA>
(UnrealNeil) butler catsup 10
<OscarL>
yeah, I mean to say... I understand what is said (it is clear enough, thank you!).... I'm just not good enough of a programmer to do much more than admire the work :-D
<waddlesplash>
ah
<waddlesplash>
well, that's fair I suppose :)
<waddlesplash>
good to know that I succeeded in clarity, at least :)
<OscarL>
+2
<OscarL>
I still rember reading about benaphores WAY back, and being equally impressed :-P
mishima has joined #haiku
<zdykstra>
also damn it, why is the Haiku GUI so pretty?
<OscarL>
Also... articles like this help me better understand things when reading actual code, so... double thanks :-)
<OscarL>
zdykstra: work of love, I guess? (and having at least some people with actual graphical talent working on it surely helped :-D)
<OscarL>
still remember some of the early discussion over using gradients on the tabs... purist went mad :-P
mishima has quit [Ping timeout: 480 seconds]
<waddlesplash>
heh, now I got a comment on HN, at just over 100 points
<zdykstra>
They took some getting used to, that's for sure :)
<zdykstra>
The icons, for me, are the best part. Nothing else comes close to them.
<jessicah>
moparisthebest: ah, yeah, that's definitely a new failure; I've also done work on porting rust libs in the past
<waddlesplash>
jessicah: pretty sure that PR I linked from a month ago is the culprit
<jessicah>
the biggest issue with rust on haiku is the lack of an equivalent of kqueue and friends
<jessicah>
waddlesplash: yep, I saw
<OscarL>
zdykstra: Stippi did an awesome job (gui/hvif).
<waddlesplash>
zdykstra: yeah, Haiku's icons really are awesome
<jessicah>
lots of things want to use mio and such, which has no haiku implementation last I checked
<waddlesplash>
we should agree on how to implement kqueue and then do it
<waddlesplash>
x512[m] has this interesting prototype using KMessage delivery to BLooper ports
<jessicah>
well, we don't need to implement kqueue itself; but yeah, something similar, but designed for haiku
<waddlesplash>
however, it requires some pretty odd additions to the port code and to BLooper to send messages back upon message receipt
<jessicah>
was wait_for_objects meant to do that?
<waddlesplash>
wait_for_objects is just glorified select
<x512[m]>
waddlesplash: I also plan to use it for sigevent with POSIX timer and async IO.
<jessicah>
ah that's right, it wasn't a single fd to wait on, right? which is the difference?
<waddlesplash>
hamishm has an old branch where he implemented an event_queue that was a stateful wait_for_objects
<waddlesplash>
which had a single FD to wait on
mishima has joined #haiku
<waddlesplash>
that's more in line with what Linux and the BSDs have, and implementing kqueue on top of it would be pretty easy
<waddlesplash>
inside libbsd for example
<jessicah>
I really should try and get into kernel dev at some point...
<waddlesplash>
x512[m]: yeah, but I wonder if it makes sense to use/require BLoopers for this. it means everything that wants async IO simply has to link to libbe and use BLoopers, which take up a whole thread
<waddlesplash>
or, they have to implement the "Reply" logic outside BLooper
<waddlesplash>
while your solution does on the surface seem more "Haiku-y" I wonder if it's not a great idea for that reason alone
<x512[m]>
I originally planned 2 modes: KMessage and raw struct passed to port. Second one can be used for pure C code.
<waddlesplash>
and thus the event_queue FD, directly building off wait_for_objects, is the better idea
<x512[m]>
POSIX timer generating KMessage's can be used to implement BMessageRunner without registrar thread.
<x512[m]>
Why FD is better idea?
<x512[m]>
It can't be integrated with BLooper event loop.
<waddlesplash>
because most of the things that want to do asynchronous IO notifications are not using BLoopers
<waddlesplash>
e.g. curl, node.js, rust applications
<waddlesplash>
they will be the major consumers of this new API; and moreover, they aren't even linked to libbe at all, much less using BLooper
<x512[m]>
Using something like waiting for both FD and BLooper port will cause unfair scheduling. For example if FD will be first, port message processing will stall if there are a lot of FD events.
<waddlesplash>
or even BMessage
<waddlesplash>
x512[m]: so, use another thread
<waddlesplash>
and that other thread can process I/O messages, and decide to generate BMessages if needed
<waddlesplash>
we are a "pervasively multithreaded" system after all
<x512[m]>
Use another thread is bad idea, introduce additional overhead and complexity.
<waddlesplash>
but we already do that all the time
mishima has quit [Ping timeout: 480 seconds]
<moparisthebest>
make it work first, optimize later, imho
<waddlesplash>
x512[m]: wineserver would use this API, won't it? doesn't it already do all IO on one thread?
<waddlesplash>
moparisthebest: sure, but that doesn't exactly apply to API design
<moparisthebest>
yea, tricky there
<waddlesplash>
you need to think about performance at least a little bit in these ares
<waddlesplash>
areas
<x512[m]>
It should be not a problem to read events from port in wineserver.
<waddlesplash>
no, but the point is, you're not using ports there already
<waddlesplash>
so I agree it does sound neat to have select/waitforobjects messages go directly to a port ... but what is the actual use-case for that?
<x512[m]>
I am against bringing Linuxish things for no reason.
<waddlesplash>
x512[m]: oh, also this is another case of string comparison overhead being introduced
<waddlesplash>
x512[m]: well, sure. but we already have wait_for_objects
<waddlesplash>
I agree very much that we should not introduce all these "fd"s objects Linux has because of epoll
<waddlesplash>
but we already have wait_for_objects which can handle multiple object types very well, so, why not extend it?
<x512[m]>
port reading fits better to Haiku design than introducing some Linux epoll like FD.
<waddlesplash>
x512[m]: under your model, every IO event message will have to do string comparisons to read the message and process it, that's not small overhead ultimately
<waddlesplash>
x512[m]: the BSDs don't have epoll, they have kqueue, it's not nearly as Linuxy
<waddlesplash>
x512[m]: oh, also ... how will your model handle fork()?
<waddlesplash>
I think you can share a kqueue across a forked process
<waddlesplash>
we don't support sharing ports
<waddlesplash>
unless I missed something
<x512[m]>
Again, I also planned raw struct mode.
<waddlesplash>
okay, but then we've got a bunch of extra complexity in the kernel
<waddlesplash>
for the 1-2 applications that *really* want to process IO events on a BLooper thread, easy enough to create a forwarding system
<waddlesplash>
we could even put it in the support kit or at least libshared, in tree
<waddlesplash>
(or, storage kit, or whatever)
<waddlesplash>
forks are the biggest thing, I think, though
<x512[m]>
An idea is allow to use existing application kit to build networking and IO-heavy applications.
mishima has joined #haiku
<x512[m]>
When fork is needed for event processing? Multiple processes can read from the same port anyway.
<waddlesplash>
they can?
<waddlesplash>
I kind of doubt many people are going to build network/IO heavy apps with the Application Kit, honestly
<waddlesplash>
network/IO "light" apps, sure
<waddlesplash>
but "heavy" apps, that's stuff like node.js or golang or rust these days
<waddlesplash>
Haiku doesn't, strictly speaking, need this API for our native apps, so we should think primarily around the consumers who do
<x512[m]>
It is very strange idea that efficient event processing is not needed for native applications. As well as abandoning making native Haiku networking/IO applications. That basically is admitting that Haiku is dead OS.
<x512[m]>
Fully featured OS should promote using native API.
<x512[m]>
If the task is only run ported applications then using original OS instead (Linux etc.) is better idea.
<zdykstra>
I was just going to say that it sounds like a job for hey
<waddlesplash>
x512[m]: I genuinely think that native applications, if they need so much event processing to warrant asynchronous processing should do it on another thread entirely
<waddlesplash>
that should be plenty efficient. we are, again, the OS of many threads, after all
mishima has joined #haiku
<moparisthebest>
augiedoggie, works beautifully, thank you
<augiedoggie>
nice :)
<zdykstra>
Insert Oprah 'you get a thread, you get a thread' gif
mishima has quit [Ping timeout: 480 seconds]
randomuser86 has quit [Remote host closed the connection]
<OscarL>
mmm Can't seem to be able to "Save as" a text file (augiedoggie's qtem-toggle.sh gist) with Web+... no file gets saved :-/
mishima has joined #haiku
<OscarL>
That was when trying to "Save as" the "raw file". Using "Download Linked file" on the "Raw" button, downloaded the file just fine.
<OscarL>
or not... can't actually find th darm file now :D
<OscarL>
wget to the rescue.
mishima has quit [Ping timeout: 480 seconds]
<OscarL>
coolio.. works like a charm, another thanks from here augiedoggie!
<augiedoggie>
:)
<moparisthebest>
augiedoggie, any thoughts on how to adjust the height or width :)
<augiedoggie>
i use the terminal profile option in the script to do that
<augiedoggie>
save a custom profile to a file from inside Terminal
<OscarL>
"windowLocation=140" works for my setup (res / Terminal font size)
<augiedoggie>
you could also do it with another hey command
HaikuUser has joined #haiku
<OscarL>
(so it get nicely horizontally centered)
<augiedoggie>
but it's easier to set the size in the profile
frkzoid has joined #haiku
mishima has joined #haiku
HaikuUser has quit []
<OscarL>
it even autohides after it looses focus?!?! double coolio.
<moparisthebest>
works perfectly, 50,0 works with max terminal size
<moparisthebest>
(to center it)
frkazoid333 has quit [Ping timeout: 480 seconds]
mishima has quit [Ping timeout: 480 seconds]
higen6 has joined #haiku
mishima has joined #haiku
<jessicah>
I removed the frame resize and used `hey ${QTERMPID} set Frame of WIndow 0 to "BRect(0, -20, 1920, 1200)" for fullscreen
<botifico-c849d97b>
[haikuports/haikuports] humdingerb 6bfff65 - Monsterz: Add type and app signature (#8511)
mishima has quit [Ping timeout: 480 seconds]
mishima has joined #haiku
<OscarL>
blockout2 could use a small patch to move its setting dir ("./bl2") out of $HOME. /me tries.
mishima has quit [Ping timeout: 480 seconds]
mishima has joined #haiku
<OscarL>
Something's odd with the blockout2 .patchset file from eblanca. After adding my small patch, and using hp -e to extract them all, the new patch set has plenty more lines modified than it should.
<OscarL>
(lots of "^M" is what gvimdiff is showing)
Begasus has joined #haiku
<OscarL>
mix of \n and \r\n, I guess?
<Begasus>
g'morning peeps
<Begasus>
'lo OscarL :)
<OscarL>
hey there Begasus :-)
<B2IA>
(UnrealNeil) 15:38 good afternoon Begasus
<OscarL>
no wonder I coudln't apply eblancas patch set when running hp with -G (was failing to apply then), but when having a git work repo, it worked.
Begas_VM has joined #haiku
<OscarL>
I think git is doing an auto-conversion of those end-lines.
mishima has quit [Ping timeout: 480 seconds]
Begasus_32 has joined #haiku
<OscarL>
UnrealNeil 2:39 AM here... guess it is morning somewhere :-D
<Begasus>
it is ... here :)
<Begasus>
g'afternoon UnrealNeil :)
<OscarL>
ah... yes... Pe shows that some (most?) of blockout sources have "DOS" line endings.
<OscarL>
Guess eblanca used an editor that didn't checked for that, or the patches he applied used only \n.
<OscarL>
heh, the patched files have "Be/Unix" line endings according to Pe. That explains why I see ^M when comparing the resulting .patchsets... git doing the right thing.
<Begasus>
part of that patchset came from other patches (debian etc I think)
<OscarL>
yeah... either those had the wrong line-endings, or those got screwed in the process of appliying them, I guess.
<OscarL>
hp -e should have fixed that on eblanca's side in anycase, I guess. Oh well.
mishima has joined #haiku
* OscarL
attempts a build after "hp -c blockout2" to see if everything applies cleanly now (even with hp -G)
<Begasus>
something needs changing there?
<OscarL>
yep, was talking abot that *right* before you logged in :-)
<OscarL>
I wan't to move blockouts settings out of $HOME.
<OscarL>
~/.bl2 looks ugly :-P
<Begasus>
ah, stored in ~.?
<OscarL>
will use find_directory() and use "blockout2" for the dir name.
<Begasus>
move it to ~/config/settings/blockout2 then :)
<OscarL>
really hate these "error: conflicting declaration 'typedef unigned int...." sigh.
<Begas_VM>
SupportDefs.h to the resque! :P
<OscarL>
guess so, with an "#elif __HAIKU__", I guess?
<Begas_VM>
should do the trick yes
<Begas_VM>
mostly I use "#if defined ..." there
<OscarL>
there's already an #ifdef WINDOW...#else... that's why I went for the #elif.
<OscarL>
aaand... I mangled the rdef somehow :-D
<Begas_VM>
makes sense :)
<Begas_VM>
nice going :P
<OscarL>
ah... this $portVersion doesn't has MINOR_VERSION, that's why... pheeew.
<OscarL>
can deal with that.
mishima has quit [Ping timeout: 480 seconds]
<Begas_VM>
tssss :P
mishima has joined #haiku
<PulkoMandy>
waddlesplash, x512[m]: regarding tonight discussion about kqueue/wait_for_object (this kind of discussion should be somewhere else than the irc channel so people can participate and not miss it in the middle of the night)
<PulkoMandy>
For netservices it would be extremely useful to have some way to process network stuff and BLooper messages in the same thread. Waddlesplash you say it's easy but netservices shows it is not at all
<PulkoMandy>
We had massive performance issues, threading problems, abuse of signals, and a few more things I don't want to remember
<PulkoMandy>
And this is not the only case where I had to solve "I want to have my BLooper handle some non-BMesage events", the other case is in the ACE emulator, but I managed to do it there by waiting for the next BMessage with a timeout
<PulkoMandy>
I don't really care which way it is done: serialize all events into a port and read them from there, or have some new API like kqueue and allow it to wakeup when a port is ready to read, alongside fds and other stuff (ideally also pthread_mutex and the like, tqatws not possible with linux epoll and it's a bit annoying)
<Begasus>
that should fix the manpages for bind_utils
<OscarL>
mmm, I will either need to change the recipe (so Lout's data ends up in data/lout/ (with no version), or find out how to get the installed version from the Pe addon :-D
mishima has joined #haiku
<Begas_VM>
patches welcome :)
<Begas_VM>
--oscar=0/1 Disable/enable Oscar part :)
<Begas_VM>
(from bitlbee)
mishima has quit [Ping timeout: 480 seconds]
<OscarL>
LOL
<OscarL>
does that disables the crazy part or the sane one. (not much difference here, really :-P)
<Begas_VM>
another python one :P
<Begas_VM>
yep ;)
<Begas_VM>
updated automake to use python3 for the test, build is fast, tests take forever ...
<OscarL>
I plant to stay away of auto* :-D
<OscarL>
s/plant/plan/
<Begas_VM>
no changes in the base packages, only for the tests (hence I'm running it) :)
mishima has joined #haiku
<OscarL>
good guy Gugasus!
<Begas_VM>
Gugasus? :)
<OscarL>
silly attempt at a word play gone wrong :-P
<OscarL>
"Good guy Gegasus" sounded even weirder :P
<OscarL>
to be fair the list was supposedly only for 3.7 :-P
<OscarL>
(and 3.8, but don't tell korli, shhh!)
<Begasus>
anythin lower then 3.7 should have been gone long ago :)
<OscarL>
lazy guys over there on Haikuports, right? :P
<Begasus>
:P
<Begasus>
openwatcom? INSTALL ... false ... :P
<OscarL>
we had openwatcom ?!?!
mishima has quit [Ping timeout: 480 seconds]
<Begasus>
PulkoMandy, did some work there, but as it says false there is nothing in the depot for it
* OscarL
founds the recipe.
<OscarL>
s/founds/finds
<OscarL>
ftp:// for the URI... you don't see that anymore these days :-/
<Begasus>
from around 2015 so ... :)
<Begasus>
patch for sparse and no recipe ...
<Begasus>
jikes 2010 :P
<OscarL>
some cleaning overdue :-)
<Begasus>
me thinks so too
<Begasus>
I'll leave the one for openwatcom, PulkoMandy can clean that too if he wants to keep it or not :)
<OscarL>
k... try 2, this time trying to build the docs from INSTALL and not from BUILD :-D
mishima has joined #haiku
<OscarL>
I'm still trying to wrap my head around the work-chroot thing.
<Begasus>
why not in BUILD?
<OscarL>
becaouse the resulting Lout doesn't seems to find its data files.
mishima has quit [Ping timeout: 480 seconds]
<OscarL>
after adding the missing $binDir/ in front of "lout"... seems to be working. /me crosses fingers.
<OscarL>
well, $prefix/bin, really (I'm on x86).
<Begas_VM>
$commandBinDir then? :P
<OscarL>
recipe said "cmd:lout" already so... who knows.
<OscarL>
seems I miss read... I was thinking of $commandSuffix.
<Begasus>
ah defaults to $prefix/bin (BINDIR not set there) :)
<OscarL>
good thing I used that then :-P
<OscarL>
too bad no fails because it can't find the OTHER command it provides... prg2lout :-/
mishima has joined #haiku
<OscarL>
actually build the package, with the 4 pdfs in it still. 3.53 MB total size.. not bad. But the missing prg2lout surely has broken at least the code examples in the .pdfs :-D
<Begasus>
it's not being build?
Anarchos has joined #haiku
<OscarL>
it think the problem is how "lout" is trying to call "prg2lout".
<Anarchos>
hello
<Begasus>
hi Anarchos
<OscarL>
seems to be looking for it on the wrong place, I guess.
<OscarL>
Hi Anarchos!
Anarchos1 has joined #haiku
<Anarchos1>
Begas_VM did you see my wonderful screenshot ?
<Anarchos1>
OscarL no trouble, i managed to get my screenshot upload to imgur :)
xet7 has joined #haiku
<Anarchos1>
Begasus maybe geany uses gsourceview too ?
<Begasus>
not to my knowlidge (in the recipe)
<Begasus>
gtksourceview* (was looking around at repology) :)
<Begasus>
outdated on haikuports it seems :)
Anarchos has joined #haiku
<Begasus>
well ... maybe not, but there is gtksourceview5 already also :)
<Begasus>
geany not listed as something using it :)
mishima has joined #haiku
<OscarL>
(Lout's package and its PDFs look great, except the example prg2lout outputs in them appears only as "??" :-D) I need more coffee.
* Begasus
hands OscarL a big cup of coffee ... extra strong
<OscarL>
awesomo!
Anarchos1 has quit [Ping timeout: 480 seconds]
<Anarchos>
512[m] i had to copy xkb files from /boot/system/data/X11/xkb to /boot/home/config/settings/xkb to get gsourceview to work
<Anarchos>
Begasus coq is a wonderful tool anyway
<Begasus>
PR comming up in a bit then Anarchos ?
mishima has quit [Ping timeout: 480 seconds]
<OscarL>
wonder if I need to add $prefix/bin to $PATH to make the recipe work :-/
xet7 has quit [Quit: Leaving]
<Anarchos>
Begasus for the xkb config files ?
<Anarchos>
Begasus anyway, time to get back to work...
<Anarchos>
see you soon, folks
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<OscarL>
didn't even got to say bye o/
<OscarL>
wish I could stop the recipe a particular point, and then enter the chroot to see what's what.
<Begasus>
put "false" at the end of INSTALL?
mishima has joined #haiku
<OscarL>
some sort of "breakpoint" but for recipes... mmm wonder if my "my "press_key_to_continue()" could work...
xet7 has joined #haiku
<OscarL>
Begasus: that might work. but be a real "break"point. no change to continue the build :-D
<OscarL>
s/change/chance/
Blendie has quit [Quit: Connection closed for inactivity]
<OscarL>
"false" it is then...
<OscarL>
darn... hp -E enters the chroot... but first it clean ups the dirs :-/
mmu_man has joined #haiku
<OscarL>
I want the enter the chroot in the state it was when it hit that "false" call :-(
mishima has quit [Ping timeout: 480 seconds]
<Begasus>
some patches around at fedora
<OscarL>
well the $PATH does points to /boot/system/bin/x86 (among others), but it doesn't includes $prefix/bin, so I guess that's why it doesn't finds prg2lout ?
mishima has joined #haiku
<OscarL>
one way to find out...
<Begasus>
;)
Begasus_32 has joined #haiku
zard has joined #haiku
<OscarL>
alright! that seems to have done the trick. will need to wait for the full build to confirm.
mishima has quit [Ping timeout: 480 seconds]
<Begasus>
progress! :)
<OscarL>
guess I shouldn't need to do $prefix/bin/lout after putting that $prefix/bin in export PATH=... :-D
mishima has joined #haiku
<OscarL>
Unable to unmount :-/
<OscarL>
but package under /hpkgs looks ok... lets see the PDFs
<OscarL>
success!
mishima has quit [Ping timeout: 480 seconds]
Anarchos has joined #haiku
mishima has joined #haiku
mishima has quit [Ping timeout: 480 seconds]
Blendie has joined #haiku
<Begasus>
nice!
<OscarL>
one last build to make sure everything is fine with my last tweaks... and to the PRs we go :-)
<OscarL>
uff hp -c fails with "read-only file system: '.self' :-D
<OscarL>
should learn to unmount /boot/system from the workdir.
mishima has joined #haiku
nosycat has joined #haiku
mishima has quit [Ping timeout: 480 seconds]
mmu_man has quit [Ping timeout: 480 seconds]
gouchi has joined #haiku
gouchi has quit [Remote host closed the connection]
<Begasus>
looking into bumping libHX
mishima has joined #haiku
<Begasus>
from version 4.* they started to use SO_DOMAIN/SO_PROTOCOL (linux only it seems)
<Anarchos>
Begasus what is libHX ?
mishima has quit [Ping timeout: 480 seconds]
mishima has joined #haiku
<Begasus>
one of the libraries in sys-libs Anarchos
<botifico-c849d97b>
[haikuports/haikuports] Begasus 9d47280 - libhx, bump to building version (#8523)
<OscarL>
that shows you how many Lout users Haiku ever had... me :-D
<waddlesplash>
PulkoMandy: x512[m]: hmm, perhaps the best solution would be, instead of forcing these events to go through a port, extending BLooper to wait on an event queue instead of just a single port
<waddlesplash>
then it can invoke some other function if the event queue has events besides the bloopers own port
mishima has joined #haiku
<x512[m]>
waddlesplash: I already said that waiting on port and something else have problem with fair event handling.
<waddlesplash>
x512[m]: no, how would that be the case? wait for objects already handles multiple events occurring just fine.
<waddlesplash>
so there may be dozens of events but as long as one of them is the port read there's no problem
<waddlesplash>
in fact this is more ideal because if things really are congested, the port will still be more usable
<x512[m]>
Multiplex all events over single port allows to properly enqueue events and handling in FIFO order without stalling events that are registered later.
<x512[m]>
Win32 have such problem: for example if you have a lot of messages to HWND, it will stop repainting and timer will stop working because user sent messages have higher priority than WM_PAINT, so WM_PAINT is never processed until all messages with higher priority are processed.
<x512[m]>
So you can easily freeze application by sending a message as result of handing another message, causing message processing loop. The same case work fine in Haiku.
mishima has quit [Ping timeout: 480 seconds]
<waddlesplash>
x512[m]: but multiplexing over a single port in FIFO order means that the io events could clog out the messages
<waddlesplash>
the same case as on Windows may work fine in Haiku, yes, but why would we "tempt fate" here?
<x512[m]>
> the io events could clog out the messages
<x512[m]>
Can you tell the details?
mishima has joined #haiku
<x512[m]>
With FIFO multiplexing any single event source can't cause other events to be not processed. Even if single event will flood 100% of time, it will be handled at 1/activeEventCount rate.
mishima has quit [Ping timeout: 480 seconds]
Anarchos has quit [Read error: Connection reset by peer]
gouchi has joined #haiku
<waddlesplash>
yes, and the same would be true for event_queue
<waddlesplash>
only one Read event would be sent until that Read event is read from the queue
<waddlesplash>
then the next Read would be sent
<waddlesplash>
so it's the same thing
gouchi has quit [Quit: Quitte]
mmu_man has joined #haiku
<x512[m]>
Adding additional event queue layer over ports in BLooper will also increase syscall overhead and kernel object count.
<waddlesplash>
kernel object count must increase anyway?
mishima has joined #haiku
<x512[m]>
Why make new entities is port is enough?
<waddlesplash>
whether the kernel event queue object delivers to a BLooper, or has its own access mechanism, there's more kernel objects
vdamewood has joined #haiku
<waddlesplash>
x512[m]: we already have this entity, it's the wait_for_objects data structure and enums, we'd just be adding a stateful interface for it
<waddlesplash>
instead of a stateless interface
<x512[m]>
One port vs one port and one event queue for each BLooper.
<waddlesplash>
no, in my proposed design, BLoopers only have event_queues attached if you need them to
<waddlesplash>
they wait on the port only without a queue, but can optionally wait on a queue instead
<waddlesplash>
avoids extra overhead and objects, indeed
<x512[m]>
More unnecessary complexity.
<x512[m]>
> Why make new entities is port is enough?
<x512[m]>
Occam's razor.
<x512[m]>
It is of course also possible to multiplex multiple ports over single port.
<x512[m]>
That will be exactly the same as event queue.
<waddlesplash>
er, where do we support that already?
<waddlesplash>
x512[m]: I think Occam's razor can also go in the other direction here
<x512[m]>
Port can be a subject of wait_for_objects.
<waddlesplash>
the additions to the port code, BLooper, and then the "reply" system you have set up in order to get events to be queued through BLooper/BMessageQueue without initiating "floods" are not simple
<waddlesplash>
a separate system for events would, in fact, be simpler than this I am pretty sure
<waddlesplash>
wouldn't that be Occam's razor also?
mishima has quit [Ping timeout: 480 seconds]
<trungnt2910[m]>
Sorry to interrupt, but with this proposal, every BLooper would loop with the wait_for_objects syscall to handle things such as semaphores and file descriptors right?
<waddlesplash>
no
<waddlesplash>
under either proposal, x512[m] or mine's, wait_for_objects is uninvolved
<trungnt2910[m]>
Then what's this even queue?
<trungnt2910[m]>
s/even/event/
<waddlesplash>
a new system that's more like kqueue/epoll
<waddlesplash>
the main question is whether to have it return events using raw structures and its own syscall (as I think it should) or whether it should just write to ports (as x512[m] thinks it should)
freakazoid332 has joined #haiku
<waddlesplash>
the "just write to ports" sounds simpler and more "native" but I think it is actually much more complicated
<x512[m]>
trungnt2910: For my proposal it will be something like wait_for_objects, but it will send port message instead of unblocking thread. So thread can read port messages to know what events are occurred. Events to be watched are attached to kernel port object and event subscription can change at runtime.
<waddlesplash>
yes, and the other proposal is basically the same, but without ports -- and it's worth noting, a prototype implementation of that has existed for years, hamishm tried it, but needs refactoring and cleanup
stux|away has quit [Quit: Aloha!]
stux|away has joined #haiku
<x512[m]>
My implementation is near complete, but I currently do different things.
<x512[m]>
I do not see any big complexity in that.
<trungnt2910[m]>
So this new system is different from _kern_wait_for_objects in the same way that epoll is different from poll on Linux?
<waddlesplash>
yes
<waddlesplash>
but epoll is just FDs only, so it's very limited
<waddlesplash>
this is more like kqueue, which supports more than just FDs
<waddlesplash>
x512[m]: I mean the amount of complexity added to, what, 5-6 different components? on its own, each is only a small amount of complexity, but added up you get a lot
<waddlesplash>
this other proposal adds 1 new system (same as yours) and touches 1 other, that's it
<trungnt2910[m]>
waddlesplash: Not very limited on a system where everything is an FD.
<waddlesplash>
trungnt2910[m]: except everything isn't a FD. they added more FD types in order to make it work
<waddlesplash>
timerfd, signalfd, etc.
DHowett_ has quit [Remote host closed the connection]
<x512[m]>
In Haiku there are various non FD objects like port_id, sem_id that can't be changed because of compatibility.
DHowett has joined #haiku
<trungnt2910[m]>
It's possible and still make sense (but not very elegant) to do the same on Haiku like semfd, portfd, teamfd,...
<waddlesplash>
definitely not
<waddlesplash>
and we usually follow the BSDs more here anyway
mishima has joined #haiku
frkzoid has quit [Ping timeout: 480 seconds]
<x512[m]>
Technically is is possible to make FD wrappers for sem_id etc.
<trungnt2910[m]>
I don't really have a deep understanding of the underlying differences between `poll` and `epoll` or similar multiplexing APIs, so...
<trungnt2910[m]>
I'm just interested as the discussion mentions getting a `wait_for_objects`-like mechanism into a core Haiku class `BLooper` which means that `wait_for_objects` (or something similar to it) would become a much more essential syscall than it is right now...
<trungnt2910[m]>
x512[m]: It might be possible right now with a `procfs` style filesystem, no?
mmu_man has quit [Ping timeout: 480 seconds]
<trungnt2910[m]>
`open("/proc/sem/[sem_id]", O_RDONLY)` and then `poll` it.
<x512[m]>
But Haiku have no procfs...
<trungnt2910[m]>
I mean by writing a custom kernel driver for it, of course.
<x512[m]>
waddlesplash: About BLooper event flooding: it can be solved by auto reset events, events that are automatically unsubscribed after enqueue. Message handler can resubscribe for event after handling current event.
<waddlesplash>
Yes, right; but that's more complicated than just a single syscall to fetch event(s)...
<waddlesplash>
it adds more complexity on *both* ends
<x512[m]>
No changes are needed to BLooper logic.
<x512[m]>
event queue will need to rewrite BLooper loop thread code.
<waddlesplash>
I thought you said you would be changing BLooper to auto-resubscribe after something is dequeued from BMessageQueue?
<x512[m]>
For message handler it is just single line of code to resubscribe.
<waddlesplash>
well that's more syscall overhead isn't it?
<waddlesplash>
now we have 2 syscall invocations for every message
<waddlesplash>
so the other proposal I'm advocating for thus has less overhead
<x512[m]>
Client code will manually resubscribe in BHandler::MessageReceived.
<x512[m]>
Not every message, only for subscribed events.
<waddlesplash>
yes, I mean every single io-events message
<x512[m]>
End for event queue case it will be also syscall overhead: first time you need to read event queue and second time you need to read port.
<x512[m]>
End -> And
Skipp_OSX has joined #haiku
<waddlesplash>
right, but that's once per loop
<waddlesplash>
yours adds it once per event
Skipp_OSX has quit []
<waddlesplash>
that's very different
Skipp_OSX has joined #haiku
mishima has quit [Ping timeout: 480 seconds]
<x512[m]>
It may be possible to collect resubscribe requests to single syscall. But such things need to be benchmarked first. Premature optimization is a root of all evil (c).
TurboFaygot has joined #haiku
TurboFaygot has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
<Skipp_OSX>
The road to hell is paved with well-intentioned code
<PulkoMandy>
I'm sorry but this discussion really shouldn't be happening over irc, we will not make any progress on such a complex topic with short messages and no usable logs. We need, I don't know, a muiling list? A forum? A bugtracker with enhancement tickets maybe?
tuaris has joined #haiku
mishima has joined #haiku
<PulkoMandy>
It is too much effort for me to read a hundred messages sent here while I wasn't looking, information density is too low, it's not worth it
<PulkoMandy>
I will add some comments in #16846
<x512[m]>
PulkoMandy: I am happy to use forum if Waddlesplash is fine.
<waddlesplash>
yes, sure
<x512[m]>
I have already mentioned auto reset events for BLooper use in #16846.
<waddlesplash>
right
mishima has quit [Ping timeout: 480 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ClaudioM has joined #haiku
<Skipp_OSX>
unrelated question, are we still doing custom background colors on Tracker windows or is that no longer a thing?
mishima has joined #haiku
mishima was banned on #haiku by waddlesplash [mishima!*@*]
mishima was kicked from #haiku by waddlesplash [mishima]
<Begasus>
waddlesplash, did some work on libtool: https://ibb.co/F67fq7w (below is the new situation for both packages, above is the current situation)
<glog78>
but i would love to use contour for the better utf8 support
<Begasus>
don't the binaries need the library to run? (if so, maybe keep the static in the base package?
<waddlesplash>
static libraries are only ever needed at build time, never at runtime
<waddlesplash>
shared libraries are needed at both times
<waddlesplash>
so yes, this is what we want: static library only, and only in the devel package
<Begasus>
ah, so it's OK to keep the static one in the other package
<nekobot>
[haiku/haiku] 3c51bd6a2bcf - libroot: Fix initialization of LocaleNumericDataBridge.
<waddlesplash>
Anarchos: what thread is it run from? that may be the trick
<Anarchos>
waddlesplash it is run from the first thread shown in debugger so i guess it is the main thread
<waddlesplash>
the first thread shown in debugger may not be the main thread
<waddlesplash>
also ... is it legal to exec() when there are multiple threads?
<Anarchos>
l1980 of team.cpp seems to imply it is legal from the main thread
<waddlesplash>
yes, but what if there's other threads active?
<Anarchos>
waddlesplash no idea, i didn't write this code
<Anarchos>
maybe i should use fork instead of exec
<Anarchos>
waddlesplash it is a posix (linux ?) app at the start
<Anarchos>
dune (a kind of make for ocaml), and this is the command 'dune exec' used to run freshly built executables
<Anarchos>
man 2 execve(linux) notes : All threads other than the calling thread are destroyed during an execve(). Mutexes, condition variables, and other pthreads objects are not preserved.
HaikuUser has joined #haiku
HaikuUser has quit []
<phschafft>
does Haiku have a posix_spawn(3)?
<Anarchos>
https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/functions/exec.html ==> A call to any exec function from a process with more than one thread shall result in all threads being terminated and the new executable image being loaded and executed. No destructor functions or cleanup handlers shall be called.
* Anarchos
is not sure if it is the relevant posix version that haiku uses.
<waddlesplash>
phschafft: yes
<waddlesplash>
Anarchos: this should probably be using posix_spawn
<Anarchos>
waddlesplash thanks for the advice, i will look at that.
<Anarchos>
waddlesplash i guess the intent is really to replace the running process with the new image ; maybe i should kill myself other threads before calling execve ?
* Anarchos
found the solution : [execve] doesn't exist on Windows, so instead we do a [Unix.create_process_env] followed by [Unix.waitpid] and finally [sys_exit]. We use [sys_exit] rather than [exit] so that [at_exit] functions are not invoked. We don't want [at_exit] functions to be invoked to match the behaviour of [Unix.execve] on Unix. *)
<Anarchos>
for this one i will put haiku on the windows side :)
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<glog78>
yes but it runs in a kvm ;) and the ui feels unresponsive (kinda)
<waddlesplash>
that's strange, ui should be extremely responsive in KVM
CPYou has quit [Ping timeout: 480 seconds]
<glog78>
it's hard to describe ... maybe the closest i would come up with is the kvm refresh feels "slow" compared to my usual 144hz work desktop (?? frametimes / refreshrate / vsync .. ??)
<glog78>
but i also can't for unknown reason utilize the full 100mbit dsl line inside of the haiku
<jason123santa>
does haiku have password locking?
<glog78>
and the biggest issue .. i guess there is no copy and paste from outside of kvm
<glog78>
so i would need to use the haiku browser which are "interesting"
<augiedoggie>
it's a bit verbose because it was dumped from a virt-manager config
<augiedoggie>
and then modified
<glog78>
augiedoggie thank you i might try this out on my next reinstall ;)
<glog78>
btw what i still didn't found is fuzzy search cli tool :( fzf doesn't compile because of a too old go and skim doesn't compile because the nix crate seems not to work with haiku
<augiedoggie>
there is at least one in the ports repository and i have a couple built that i toy around with
<augiedoggie>
most of them don't play nicely with the Haiku terminal
<glog78>
yeah
<augiedoggie>
i guess i was thinking of 'hstr' which is specific to history searching
<glog78>
i search something to include into a vim setup
<glog78>
so the options with a ready to use plugin are limited
<glog78>
i am already happy that clangd is running
<augiedoggie>
i have pick/percol/selecta built and mostly fine
<augiedoggie>
i kludged heatseaker into running but it was unhappy
<braewoods>
Hello. I've been doing research on Haiku's available kernel APIs trying to see if there's a way to implement something in the future. I have a very specific use case where I am trying to write userspace code to drive USB screens that either use a custom serial protocol through a USB serial interface or through a custom USB driver. Essentially I want to see if there is a way to map a given USB device to its
<braewoods>
corresponding serial port, or to find the USB device behind a given serial port. So far I have found nothing in the source code to suggest this is possible from a userspace API. Anyone know more?
AlaskanEmily has joined #haiku
<braewoods>
If all else fails I can leave it up to the user to figure out the mapping but if I can do it automatically that would be better.