<Skipp_OSX>
I'm trying to fix a drawing bug in Deskbar. Open virtual window e.g. Applications, select an item, resize name, selection rect is tinted bc bg color not white
<Skipp_OSX>
but that' s not really relevant I just want to fix the colors right now
<jessicah>
not in my install
<jessicah>
guess I should do an update; but I don't recall seeing anything in commits
<Skipp_OSX>
yeah not editable in your install, but there's still a bug in your install
<jessicah>
then I need a reproducible I can see :)
<Skipp_OSX>
oh no it's not been included yet so no update will help but the bug exists on R1B4
<Skipp_OSX>
did you select an item?
<Skipp_OSX>
you have to have an item selected or you won't see the bug
<jessicah>
what is bc in bc bg
<jessicah>
what is the behaviour?
<Skipp_OSX>
how are you not seeing the highlight color changing from black to gray?
<Skipp_OSX>
when you resize the name column
<Skipp_OSX>
on a virtual window (one with gray background)
<jessicah>
renders fine here
<augiedoggie>
i see that problem and others :P
<Skipp_OSX>
maybe you're install pre-dates the bug
<augiedoggie>
just selecting the items causes the date column to shift a few pixels
<jessicah>
I'm on 56910
<jessicah>
56910+24, whatever that means
<jessicah>
ah, maybe my jmap branch
<Skipp_OSX>
you holdin' out on me? hehe
<jessicah>
it's not ready
<jessicah>
well, it goes to grey when I click outside the window, is black in the window; resizing, no colour changes
<Skipp_OSX>
yeah that's normal background window drawing
<jessicah>
the only commit is yours, so yours must be introducing the bug? :p
<Skipp_OSX>
maybe!
<jessicah>
hmm, that doesn't change anything in PoseView.cpp
<Skipp_OSX>
but if so it's in R1B4
<Skipp_OSX>
so I introduced the bug a while back
<jessicah>
hmm, but it's not in my install
<Skipp_OSX>
:/
<Skipp_OSX>
how did you fix it?
<jessicah>
let me see how old my current install is
<jessicah>
2023-04-08
<Skipp_OSX>
I thought you said it was 56910 that's not too long ago yeah that's right
<Skipp_OSX>
so no way you aren't bugged unless you patched it
<jessicah>
maybe it's a bug in your local tree?
<Skipp_OSX>
you could change document background color to be a little gray and open a regular folder and put it in column mode too to reproduce the bug
<jessicah>
hmm, foreground colour changes
<Skipp_OSX>
yep
<jessicah>
let me see if there's a subtle change
<jessicah>
oh, I thought you said background
<Skipp_OSX>
no it's trigged by the background color not being white
<Skipp_OSX>
because it does InvertRect I'm assuming
<jessicah>
the selection colours are something else entirely
<Skipp_OSX>
well right and wrong are kind of subjective but the highlight color being black is the intended color although I don't really care as long as it's consistent
<jessicah>
then you don't want LowColor()
<Skipp_OSX>
I don't want the inverse of LowColor() either
<Skipp_OSX>
that red is the inverse of that lovely cyan color you've chosen
<Begasus>
last thing on the PR for vis/libtermkey (commented) Habbie :)
<Begasus>
Morning zdykstra
<Begasus>
Ola OscarL
<OscarL>
Hello Begasus, zdykstra :-)
<zdykstra>
Hey OscarL :)
<OscarL>
speaking of merges, my AboutSystem patch got merged, without even passing the Commit checker bots. Not sure if I should feel happy, or scared, about that :-P
<OscarL>
Begasus, as you have 1000+ packages installed, have you noticed a big difference on boot speed compared to a smaller install on the same hardware?
<Begasus>
probably yes OscarL
<OscarL>
(asking to compare, now my 32 bits install takes considerably longer than my 64 bits one, wasn't the case a couple weeks ago :-D)
<Begasus>
but it's been that way for a while :)
<OscarL>
yeah... was thinking that... "unless he tries with a clean drive..." :-D
<Begasus>
Cleaning out most of the states also from time to time
<OscarL>
that helps, but to get into the boot menu, for me.
<Begasus>
think it's due to the packages and packagefs
<OscarL>
(othewise it gets really sluggish)
<Begasus>
with pressing shift or space at boot?
<OscarL>
yup. with too many states, it takes longer to enter it for me.
<Begasus>
picking the right one will be tricky too then ;)
<OscarL>
(slow PC/HDD certainly does not helps).
<OscarL>
indeed. Can we actually rename those folders? Would be kinda cool: "Use_this_state_in_case_of_emergency-hrevxxxx" :-)
<Begasus>
heh
* OscarL
sees trungnt2910[m] screenshot. WOW, nice going!
<Begasus>
I have to delete some of those anyway, with the installing/uninstalling of packages it tends to misbehave (trying to re-install one from the saved states)
<OscarL>
HaikuDepot/SoftwareUpdate not playing 100% nice with locally build package (or HOME installs) also doesn't helps to avoid some traps.
<Begasus>
Keeping away from HOME installs here :)
<OscarL>
I really like them, but seems to have some rough edges on its own, and some packages just break :-D
<OscarL>
Lout works fine on both at least :-P
<OscarL>
(and even Pe support for it does in both cases... well that's with my pending PRs applied)
<Begasus>
ok, how did I get burp to connect last time ...
<OscarL>
mmm, Habbie was right (from the IRC logs): using "LUA_CPATH=/system/lib/x86/lua/5.3/?.so vis" allows vis' lua to find its lpeg module.
<OscarL>
guess we need to decide which one of the two solutions proposed by augiedoggie to use... move lpeg.so out of x86, or patch LUA_CDIR :-D
<augiedoggie>
probably the latter
<augiedoggie>
although it would be easier to move lpeg
<OscarL>
guess I can try both, one on 5.3, and the other for lua54? :-D
<Begasus>
got it ... KDL (even with older librsync) :P
<Begasus>
reproducable, so guess time for a ticket
<Begasus>
at least I know it's not librsync that is having problems :)
Begasus_32 has quit [Read error: No route to host]
talos has quit [Remote host closed the connection]
talos has joined #haiku
Diver has joined #haiku
Diver is now known as Diver
<OscarL>
(Habbie's libtermkey' PR could use a rebase... its 357 commits behind, and makes switchingt between branches a bit of a pain on this slow PC :-D)
<OscarL>
that, or get merged :-D
dby has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
it's fine as it is, you just can't call pkgconfig on it as it is atm :)
Blendie has joined #haiku
Begasus_32 has joined #haiku
<Begasus>
oh, just read it, concarts on the patch getting merged OscarL :)
<OscarL>
thanks!
<OscarL>
small thing but, considering my broken brain... make me happy to actually fix something :-D
<botifico-c849d97b>
[haikuports/haikuports] Begasus 24f3da2 - librsync, revbump for rebuild (#8552)
<Skipp_OSX>
hey Diver can you recheck BeControlLook again when you get a chance see if it's working better now?
<OscarL>
jessicah: I concurr :-). Took a bit to get to HyClone -> "Haiku clone, ah!" (but that might be my poorly self-taught "English").
<Diver>
Skipp_OSX: hi, any specific ticket?
<Diver>
trungnt2910[m]: ah, that was it
<Diver>
now I'm getting Starting launch_daemon
<Diver>
_kern_loading_app_failed
<trungnt2910[m]>
That said, I might set a "default" $HPREFIX at `$HOME/.hprefix`.
<trungnt2910[m]>
Diver: stat $HPREFIX/boot/system/servers/launch_daemon
<trungnt2910[m]>
Does launch_daemon exist?
<Diver>
yep, it's there
<trungnt2910[m]>
ps aux | grep launch_daemon what does this show then?
<trungnt2910[m]>
tail -f $HPREFIX/.hyclone.log might also be helpful.
<Skipp_OSX>
idk right now
<trungnt2910[m]>
<Diver> "now I'm getting Starting..." <- I _think_ I know the cause. You mentioned running `haiku_loader bash --login` and got `_kern_loading_app_failed`. That's because you haven't set up `$HPATH`. You might want to either do an initial `export HPATH=/boot/system/bin:/boot/system/non-packaged/bin` or specify the full path of `bash`: `haiku_loader /boot/system/bin/bash --login`.
<Diver>
haiku_loader /boot/system/bin/bash --login works, however it takes ~8 seconds to start
<Begasus>
there, ticket filed, PR for latest burp created (draft) :)
hightower3 has quit [Ping timeout: 480 seconds]
<trungnt2910[m]>
Diver: That's expected as even the normal Haiku terminal does a bunch of things before starting.
<trungnt2910[m]>
Running bash without --login is a bit faster but will not initialize the necessary environment variables like $PATH.
<trungnt2910[m]>
Or running a single command like haiku_loader /boot/system/bin/uname -a.
<trungnt2910[m]>
Another way is to kill launch_daemon and then launch it again: /boot/system/servers/launch_daemon. Ensure that ps shows these processes:
<Diver>
it now stuck after Welcome to the Haiku shell.
<trungnt2910[m]>
Diver: Seems like `package_daemon` is running but a few deps are missing. `build_hprefix.sh` does not do any dependency resolution and does not install some other bloat that Haiku needs. If the problem persists a `pkgman full-sync` might help.
<Diver>
~> pkgman full
<Diver>
*** failed to add system packages to system repository: Bad port ID
<trungnt2910[m]>
Impossible. What does ps from a Haiku shell show?
<trungnt2910[m]>
Also what's your distro, I might want to set up a VM and look at it.
<trungnt2910[m]>
trungnt2910[m]: The output above means that `launch_daemon` is not running. But the logs on pastebin indicate that it _was_ running.
<Begasus>
LOL, still got boost163 installed on 64bit :P
<nekobot>
[haiku/haiku] 035715568380 - Update translations from Pootle
xet7 has joined #haiku
pvalue has quit [Quit: Vision[]: i've been blurred!]
<OscarL>
so... the main lua package does not includes nor provides liblua.so, so programs that needs it have to require the _devel package for a runtime dependency? Doesn't sounds correct, no?
<Begasus>
it shouldn't contain liblua.so
<OscarL>
and considering lua is generally used as an embedded scripting language (even Dano used it for decorators), I'm not convinced of not providing the static library in this case.
<Begasus>
no package (base) provice the lib*.so one
<Begasus>
what would be the difference, the static one would also be in the devel package?
<jessicah>
being embedded would be the difference, and it'd drop any lib dependency when installed
<jessicah>
so lua non-devel wouldn't be required
<Begasus>
a dependency to liblua.so.5.3 isn't enough (rookie her on that matter), it hasn't been an issue before?
<OscarL>
not sure I'm expressing myself right... sigh... (be back when I can do so, or when things get clearer for me)
<Begasus>
np :)
hightower2 has joined #haiku
<OscarL>
comparing with Python for example... python provides... "python3.10" (package), various "cmd:s", lib:python3.10, AND devel:libpython3.10.
AlaskanEmily has quit [Remote host closed the connection]
<OscarL>
lua seems to only provide: lua (package), some "cmd:"s, lib:liblua, but not "devel:" (and then, for example, lua_x86 package does not contains any lib, that I assume programs whishing to load it at runtime would need).
<Begasus>
here the lua_x86 package contains the binaries and the library liblua.so.5.3
<OscarL>
on python packages, you get stuff under /bin, data/, develop (guess we just don't have a separate package for that), AND stuff under /lib. the last one is the one I'm expecting to see on the lua ones.
<trungnt2910[m]>
<Diver> "ubuntu 20.04 with linux kernel 6..." <- I've tried HyClone on Ubuntu 20.04 WSL1, it works well, except that HyClone crashes during first boot processing so might have to kill everything (`killall -9 haiku_loader hyclone_server`) and start HyClone again.
<trungnt2910[m]>
I'm currently setting up a Ubuntu 20.04 VM and building HyClone on that one, but it'll take a while as it's compiling Haiku's buildtools from scratch.
<OscarL>
Begasus might be some problem with my local builds then (weird, didn't even touched those). Rechecking.
<OscarL>
(just unninstalled everything, and will start again)
<OscarL>
Thanks Begasus. Something wrong on my end (besides my head? :-P).
<Begasus>
you got me scared ;)
<OscarL>
Sorry!
<Begasus>
np, can handle a few ;)
<B2IA>
(UnrealNeil) my son has setup a beshare server... but I cannot connect... I don't know what to advise him. He can connet both on the local IP and the public IP...
<B2IA>
(UnrealNeil) (in another house/building away from me)
<B2IA>
(UnrealNeil) tokumei.online
floof58 is now known as Guest12498
floof58 has joined #haiku
<B2IA>
(UnrealNeil) Ok, he's made a setting change... I'm off to try it. BRB
<Begasus>
k, thinking of dropping gcc2 support for texinfo, the binaries can still be installed in $prefix/bin ... (latest release)
<Begasus>
running into parse errors over and over :P
<B2IA>
(UnrealNeil) bulter catsup 15
<B2IA>
(UnrealNeil) bulter catsup 15
<Diver>
trungnt2910[m]: I rebooted and now it stuck at
<B2IA>
(twozakai) I can send... and I can receive...
<Begasus>
'lo there :)
<OscarL>
hello twozakai. (can barely read your nick, damn IRC client with fixed colors :-D)
<B2IA>
(UnrealNeil) twozaki: on your server?
BrunoSpr has quit []
<B2IA>
(twozakai) I can connect locally to my server and I can connect to it from my WAN IP
<B2IA>
(twozakai) and I can send and receive between two beshare clients, one connected to 192.x.x.x and one connected via the WAN IP
<B2IA>
(UnrealNeil) ok, i'll try with th IP
<B2IA>
(UnrealNeil) nice
<B2IA>
(twozakai) DNS name also working, tokumei.online:7000
BrunoSpr has joined #haiku
HaikuUser has joined #haiku
BrunoSpr has quit []
zeldakatze has joined #haiku
zeldakatze has quit []
HaikuUser has quit []
zeldakatze has joined #haiku
<OscarL>
Begasus, just in case... I removed ALL lua*.hpkg, run "pkgman full", "checkfs /boot", and git pull upstream master. Things should get better after a reboot, I reckon?
<B2IA>
(UnrealNeil) butler catsup 10
<B2IA>
(twozakai) yup, I suspect there is a comman-line flag I need to enable/configure
BrunoSpr has joined #haiku
<Begasus>
it should be OscarL
<Begasus>
provided no Haiku changes a reboot wouldn't be needed
BrunoSpr has quit []
<OscarL>
was missing last +79 patch.
<Begasus>
ah
<Begasus>
had that today for the 64bit install
matt1 has joined #haiku
<B2IA>
(UnrealNeil) twozaki: IF it works for you... it should work for me. I couldn't see a switch of interset in thet screen shot your sent...
<B2IA>
(twozakai) the only thing I can think of is something to do with what address it listens on... but the server only HAS one address... and only one address has been forwarded...
<OscarL>
Begasus: Back on track: liblua.so.5.3 is in system/lib/x86 now, pheew! No idea what was that. Sorry for the noise.
<Begas_VM>
+1 :)
<B2IA>
(UnrealNeil) butler catsup 5
<OscarL>
for newest Lua, do we still want to provide a GCC2 version (nothing seems to require liblua5.4)
jmairboeck has joined #haiku
<Begas_VM>
checked the recipe? I think so*
<Begas_VM>
or pkgman search *
<OscarL>
"inrecipe lua5.4" only shows results on lua recipes (for conflicts with _devel :-D)
<Begas_VM>
that I know, lua5.3 is still the default (only one providing cmd:lua liblua.so (in devel)
<OscarL>
that would explain the CONFLICTS on the others, yup. lua5.4 recipe seems to be mising one for lua5.3 :-/
<OscarL>
duh, it has it, but as "lua" (silly me)
<B2IA>
(UnrealNeil) Twozaki: I'm just downloading JavaShare2 for Windows, to give that a whirl...
<Begas_VM>
heh
<OscarL>
(using explicit numbering would be neater, thou :-D)
<B2IA>
(twozakai) I couldn't get javashare running on archlinux, missing some GUI dependancies and there wasn't any documentation for it
<B2IA>
(UnrealNeil_ViaWindows) Twozaki: I'm back
<B2IA>
(UnrealNeil_ViaWindows) Now to try your muscle server
<OscarL>
(I think there could be a basically empty package that points to the default one.)
<PulkoMandy>
OscarL: hello, I think I just fixed the crash in BGhostView :) let me know if it works for you
<OscarL>
"pkgman install lua" (and "lua" depends on whatever is the default lua_xxx on that platform)
<PulkoMandy>
I will try to change the icons to use more modern ones and then I think we can have a release to update in HaikuPorts
<OscarL>
PulkoMandy: nice! Will test right away.
<OscarL>
PulkoMandy: built/tested a local recipe poiting to 2560136424c147c9edc3d19d1604ebf12a09cce6... It seems to work fine!
<OscarL>
tested changing pages/zoom, paper size...
<OscarL>
will try a big .ps now.
<PulkoMandy>
nice :) I'm replacing the icons with newer ones now, and then I'll tag a version 1.0.0 :)
<OscarL>
Seems to handle complex files just fine too. Will have the recipe almost ready for that 1.0.0 tag :-D
<B2IA>
(UnrealNeil) butler catsup 5
<OscarL>
Begasus, should I reply to nielx regarding the old rust recipes, or you'll do it?
<trungnt2910[m]>
<Diver> "trungnt2910: I rebooted and..." <- I've done setting up my Ubuntu VM and I can reproduce your bug. I'm currently working on a fix.
<Diver>
nice! :)
<OscarL>
Begasus, now that I see the history for dev-lang/rust/, seems nielx hasn't touched that dir since 2017 :-D (and he *does* "git mv" for the ones under "dev-lang/rust-bin")
<Begasus>
haven't seen it yet :)
<PulkoMandy>
rust-bin is cross compiled from Linux. I think it is currently not possible to build Rust directly on Haiku
* OscarL
notice the BGhostview release, YAY
<Begasus>
commented OscarL
<PulkoMandy>
yes, now with nice vector icons :)
<OscarL>
PulkoMandy: does adding "2019-2023 Adrien Destugues" to the current 'COPYRIGHT="1999 Andreas Raquet"' on the recipe sounds about right?
<PulkoMandy>
yes, I guess
<OscarL>
Great. Thank you! (will open a PR for 1.0.0)
<botifico-c849d97b>
[haikuports/haikuports] OscarL 981f2b0 - BGhostview: update to version 1.0.0
KapiX has joined #haiku
<B2IA>
(UnrealNeil) butler catsup 10
braewoods has joined #haiku
tuaris has quit [Quit: Leaving.]
<braewoods>
Is there a preferred place to put unix sockets in the file tree of Haiku?
<braewoods>
It's also common practice to use PID files for unix system background services. What is the preferred practice for Haiku?
OscarL has quit [Read error: Connection reset by peer]
OscarL has joined #haiku
mmu_man has joined #haiku
<OscarL>
Not sure braewoods, maybe on B_{SYSTEM,USER}_CACHE_DIRECTORY or B_{SYSTEM,USER}_TMP_DIRECTORY ?
<OscarL>
B_{SYSTEM,USER}_VAR_DIRECTORY perhaps?
<braewoods>
Under Linux it's /run or /var/run. BSDs and SunOS are /var/run apparently.
<braewoods>
But given how atypical Haiku is I may just use /tmp.
<OscarL>
finddir -l will give you a list of B_xxx_DIRECTORY that you can use to "finddir B_SYSTEM_VAR_DIRECTORY", for example
<OscarL>
there's also <FindDirectory.h>
<Begas_VM>
ok, pathological needs pygame_x86 to run, but the game can be build for "all", should I switch to secondary arch to add pygame as dependency?
<braewoods>
OscarL: thanks, is there a preferred way to run background services?
<braewoods>
Part of my project is intended to be run as a background process.
<braewoods>
Under most unix clones I would integrate with init's service system, whatever that is.
<OscarL>
all I know about background programs, is how to make them avoid appearing on Deskbar :-) (you need to set the "Background app" flag on their resources)
<OscarL>
we have a "launch_daemon"
zeldakatze has quit [Quit: Vision[]: i've been blurred!]
<braewoods>
Ok. I'll investigate it later.
<OscarL>
seems to be called "launch_roster"?
<braewoods>
just trying to find the best way to port my design to Haiku as I implement it
<jmairboeck>
Begas_VM: probably pygame_x86 should add pygame to PROVIDES, like it is done for a few python recipes
<OscarL>
braewoods: /boot/system/data/launch/system is a text file, that shows how "services" gets launched at boot (AFAICT).
<OscarL>
sorry for being vague, just not something I'm really familiar with (as usual :-P)
<braewoods>
yea, it's not something I'd normally need to care about but when you write long running process code, you suddenly need to care more about implementation details
<OscarL>
asking around again at other hours will certainly get you better answers, or you could try over the forums.
<braewoods>
I found something interesting though. I was trying to find out why some unix clones failed to enumerate my turing smart screen so I could get a serial interface. It boiled down to differences in how they enumerate USB CDC ACM devices.
<OscarL>
Begas_VM, FWIW, on "monsterz" I put: "# For 32 bits, only "pygame_x86" is available, thus we can't use "any" here."
<braewoods>
NetBSD / FreeBSD looked somewhere else than Linux and OpenBSD did.
<braewoods>
I guess my users will just have to live with this limitation as I doubt I could get this issue patched. They'll probably just say my device is faulty which it probably is, technically.
<OscarL>
always fun doing cross-platform development :-D
<braewoods>
Yea, if the device had the same value in both descriptors it would have worked fine but I can't fix that since I didn't make the device.
<braewoods>
And from what I can tell the bugged drivers cannot be unloaded to be replaced with a userspace one as a workaround.
<braewoods>
So I guess it just has to be as it is.
<braewoods>
It won't be the only display I intend to support.
<braewoods>
But I should probably stick to USB ACM serial via posix termios APIs plus custom libusb drivers.
<OscarL>
that reminds me... our pc_serial driver still doesn't handles timouts :-/
<OscarL>
(or not well enough via BSerialPort class at least)
<OscarL>
damn thing preventing my serial_mouse driver from working!!!
* OscarL
shouts at clouds.
<braewoods>
Eh? I thought pc_serial was only for RS232.
<OscarL>
yup.
<braewoods>
I thought you were talking PS/2.
<braewoods>
I've never heard of a serial mouse, just PS/2, USB, bluetooth.
<OscarL>
na... good old serial mouse :-D
* OscarL
feels old
<braewoods>
Must be older then.
<braewoods>
I'm used to PC hardware.
<OscarL>
and where do you think I was using those serial mouse drivers? :-D
<OscarL>
PC all the way... just older :-D
<braewoods>
the original XT?
<OscarL>
started with that... but I still have machines with serial ports, and working mouse to try
<OscarL>
in fact... my current Phenom II X4 machine (this one) has serial and parallel ports.
<braewoods>
Someone was making modern motherboards that are based off the XT architecture.
<braewoods>
Modified for modern cases and the like.
xet7 has quit [Ping timeout: 480 seconds]
<OscarL>
heh, I guess some people like working with hardware that old. I like seeing repair videos on them, but actually use them? nah... I *was* there :-P
<braewoods>
Ever hear of ELKS?
<braewoods>
a Linux clone designed to run on x86 real mode, no memory protection
<OscarL>
similarly... could we make x86 for lua be the primary, and drop the gcc2 one? at least for newer versions?
<Begas_VM>
story is a bit different then with python packages :) (arch independent locations)
<Begas_VM>
;)
<OscarL>
:-(
<Begas_VM>
but np, can switch to secondary arch for pygame :)
<OscarL>
mmm "inrecipe pygame" only results: monsterz and singularity (besides the pygame's own recipe)?
<OscarL>
what's the story regarding SDL 1 vs SDL 2?
<OscarL>
much difference building pygame agains one or the other?
<OscarL>
*against
hightower2 has quit [Ping timeout: 480 seconds]
<Begas_VM>
not following ...
<Begas_VM>
got caught up in playing phatological :)
gouchi has quit [Remote host closed the connection]
<OscarL>
heh. I mean... seems like pygame can be build with either SDL1 or SDL2... and I was wondering if there's a reason to keep it on SDL1.
<OscarL>
and considering that we seem to have only 2 (3 with Pathological) games using it... might be good time to switch to the newer, unless there's a problem with that.
<Begas_VM>
SDL2 has become better in the last years, before that it had it's faults (slow/dragging ...)
<Begas_VM>
for instance TuxPaint stayed on SDL for quite a while because of this, now it works fine with SDL2
<OscarL>
I see (reading SDL issues on github now, to see what I find)
<Begas_VM>
Bill even dropped support for SDL in favor of SDL2 now
<OscarL>
what/who is Bill?
<Begas_VM>
Bill Kendrik author from TuxPaint
<PulkoMandy>
braewoods: I am looking into hardware flow control for USB-ACM and it doesn't look like there is any way to configure it in standard USB CDC-ACM, so nothing more we can do in our driver. The hardware may or may not implement flow control on the actual UART side (if there's even a physical UART there), and on the USB side it's expected that USB already provides all the flow control you need (the device ca
<PulkoMandy>
n reject requests to send data if it has no buffer available, and the computer will try again later). So, I don't think enabling or disabling hardware flow control will do anything. However, it looks like it is possible to directly control RTS and DTR pins, I don't know if our driver already handles that
<PulkoMandy>
it looks like it does, in ACM::SetControlLineState. So I don't think the ACM driver can do anything more than it already does here
Blendie has quit [Quit: Connection closed for inactivity]
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
copy has quit [Remote host closed the connection]
copy has joined #haiku
hightower2 has joined #haiku
<braewoods>
PulkoMandy: doesn't matter anyway, the device I was looking at isn't really anything to do with networking, modems, etc. It just implements a minimal ACM driver to emulate a serial port it can receive proprietary commands from for controlling the device.
<braewoods>
So it could be interfaced with regular OS usb drivers.
<trungnt2910[m]>
<Diver> "trungnt2910: I rebooted and..." <- The problem is `registrar` crashing while trying to do something at the `NULL` address. The bug is only reproducible on Linux, and not on WSL1. However, even after nuking two VMs I still can't find the root cause of that bug.
xet7 has joined #haiku
<Begas_VM>
cmake files for openjpeg or installed in $libDir instead of $libDir/cmake, not touching that atm ...
Begasus_32 has quit [Quit: Vision[]: Gone to the dogs!]
bbjimmy has joined #haiku
<PulkoMandy>
Yes, that's what ACM is for, simple serial communications over USB. Not normally used for actual modems and networks (other USB-CDC profiles are available for that)
<OscarL>
Lagrange crashes on resize (wonder if it can be built with -DENABLE_X11_SWRENDER, using waddlesplash' xlibe)... one way to find out?
<Begasus>
PR created ... time to head out for a bit :)
<Habbie>
i'll rebase
<Begasus>
cu later
<OscarL>
later.
<OscarL>
thanks Habbie! (slow HDD here, and the dependecy thing that HP does gets kinda painfull :-D)
<Habbie>
yes! i noticed on my previous machine
<OscarL>
Building Lagrange with xlibe? no go. Guess we should just not resize its windows then to avoid the crash :-P
HaikuUser has joined #haiku
HaikuUser has quit []
<OscarL>
ah... I see that gitk has the same resize->crash issue (SDL2/OpenGL).
<OscarL>
(Should have saved the compiler error :-/)
<OscarL>
something missing on an anonymous union, IIRC.
<OscarL>
the idea was to use X11 for to make use of Lagrange's -DENABLE_X11_SWRENDER option (I was trying to avoid OpenGL) to see if that helped with the crash on resize.
<waddlesplash>
well, please do let me know what the error was
<waddlesplash>
it may be fixable
<waddlesplash>
but really, we should just figure out what's wrong with SDL and fix it instead