ChanServ changed the topic of #haiku to: Open-source operating system that specifically targets personal computing. | | Nightlies: | Bugtracker: | SCM: | Logs: | Matrix: | XMPP:
FreeFull has quit []
Maturi0n has joined #haiku
Maturi0n_ has quit [Ping timeout: 480 seconds]
mbrumbelow has joined #haiku
<waddlesplash> braewoods: what do you mean by "find" the usb device behind a given serial port?
<waddlesplash> USB serial devices will appear in /dev/ports/usb/
<braewoods> waddlesplash: from what I can see, under /dev/ports enumerates usb serial ports as usb followed by an integer.
<braewoods> But how do I know which USB device caused it to be created?
<braewoods> What hardware does it belong to on the USB bus?
<braewoods> Under say Linux I could probe /sys to find the serial port that a USB driver created or the reverse.
<braewoods> e.g., ttyUSB or ttyACM.
<braewoods> This would be useful if I am trying to find a specific device's serial port interface.
<waddlesplash> hmm
<waddlesplash> if you look in the "Devices" app, does it show up there?
<braewoods> I'll take a look. Moment.
<waddlesplash> the USB stack is not especially well integrated into the kernel device manager system
<waddlesplash> a bunch of refactoring is still needed
<waddlesplash> however, we may have gotten to the point where it will show up in there
<waddlesplash> yeah it appears we don't
<braewoods> it does show up, but just the raw USB device.
<waddlesplash> I have HID devices but in Devices app it just lists the bus hub as the driver
<braewoods> Ok. In my case I was researching what features I might plan to have beyond Linux. My code will probably still work due to the POSIX layer but some features require OS extensions to work at all.
<waddlesplash> what does SerialConnect display?
<braewoods> usb0, basically just the device name.
<waddlesplash> yeah, ok
<waddlesplash> we probably should improve this, indeed
<braewoods> which doesn't help if I'm trying to pair it up with its device.
<braewoods> But it seems to be a common problem. Most of the BSDs also lack a similar thing.
<waddlesplash> there are at least 3 potential ways to fix this
<waddlesplash> 1. rename what winds up in /dev/ports/usb/ (easy enough, not sure if that will cause problems elsewhere however)
<waddlesplash> 2. add a custom ioctl to usb_serial (or find a generic one that we should be implementing anyway) to return this information
<braewoods> actually no directory is created, unless this is recent? I was using the latest beta.
<waddlesplash> 3. refactor more of the device manager to get the information into there
<waddlesplash> braewoods: oh, right, I'm misreading this code. indeed it's just usb0, etc.
<waddlesplash> that could also be changed, but, that may break existing software which expects just files in this folder
<braewoods> which is fine, it's enough to filter out non-USB ports, just not enough to know anything about the backing device.
<waddlesplash> right
<waddlesplash> any standard ioctl for this?
<braewoods> Not really, given that USB isn't even recognized by POSIX. Every OS has their own USB API.
<braewoods> libusb has to be ported to every variation that exists.
<waddlesplash> no, I mean a standard TTY ioctl, to get information about the TTY on the other end of the line
<braewoods> Oh.
<waddlesplash> braewoods: btw our libusb port really has problems :(
<waddlesplash> it misbehaves in ways that don't make any sense. I think people have tried to fix it to no avail
<braewoods> Like what?
<waddlesplash> using the native userland USB APIs, which are honestly pretty similar to the libusb APIs, works great
<braewoods> It could be from trying to mix C and C++ improperly.
<waddlesplash> I don't remember specifics, just that I know PulkoMandy has written native Haiku USB backends to some pieces of software and they work way better than the libusb ones
<waddlesplash> braewoods: heh, we are experts at mixing C/C++, I sincerely doubt that's the problem
<braewoods> I see.
<braewoods> I've mostly written C code, minor contributions to Linux kernel.
<waddlesplash> here's one example, an upstream'ed backend to android-file-transfer using the native APIs, which as you can see are very straightforward
<braewoods> If you were wondering, I was wanting to essentially create a portable client/server model that can manage USB connected displays in a generic manner.
<waddlesplash> braewoods: I actually know less about USB in practice than you might expect; I've not written any USB device drivers
<waddlesplash> ... but I'm the maintainer of Haiku's XHCI driver
<braewoods> Some example devices? The turing smart screen, vocore displays, or the many ax206 variants floating around.
<waddlesplash> (and rewrote most of it around 2019. the older version was ... not great)
<waddlesplash> hmm, interesting concept
<waddlesplash> well, it should definitely be possible to do this with haiku, and if it isn't, we should fix
<braewoods> It would only be useful for the USB serial ones like the turing one. The others use custom drivers so this isn't an issue
<braewoods> I saw the kernel driver's class exposes the usb_device it contains. Maybe that can be used?
<waddlesplash> you mean the usb_serial SerialDevice class?
<braewoods> yea, i think so.
<waddlesplash> well, yes, but nobody else can call that but other code in the usb_serial driver
<waddlesplash> so, we need to decide how or where this data gets exposed
<braewoods> Figured.
<waddlesplash> all drivers on haiku are dynamically linked btw
<braewoods> I wasn't 100% sure since it's hard to figure out how kernel stuff works.
<waddlesplash> there is no symbol resolution except into the kernel
<waddlesplash> (that's honestly a bit of a downside in the USB stack, I'd really like to fix that part)
<braewoods> does haiku actually use users at all? it seems like everything runs as root.
<waddlesplash> but it will come with some potential hazards, so, that likely can wait
<waddlesplash> braewoods: yes
<braewoods> or user rather.
<waddlesplash> not by default, but you can useradd, login, etc.
<braewoods> so file permissions actually matter?
<waddlesplash> in fact sshd is basically useless out of the box, because we don't set PermitRootLogin
<waddlesplash> yes ... theoretically
<waddlesplash> until a few years ago most filesystem drivers and the VFS weren't good about actually checking them
<waddlesplash> that has since been fixed, there are actual permissions checks done now, however I don't think this has really been stress-tested
<braewoods> Not complaining, but what inspired my program idea is the fact that most USB code has to run as root just to work so I thought why not make the server and client separate?
<braewoods> waddlesplash: it's fine, doesn't matter much to my program, i was just surprised.
<waddlesplash> well, this is mostly due to BeOS compat at this point
<braewoods> i guess it shows that Haiku wasn't really designed for multiuser systems per say.
<waddlesplash> I bet if I actually tried, I could get the GUI to run as something other than UID 0 in not much work
<waddlesplash> braewoods: nah, the kernel developers clearly thought about this
<waddlesplash> they were preparing for the day to come, and it's slowly coming
<waddlesplash> when I do cleanups or refactors I try to audit for this and add missing pieces where necessary
<waddlesplash> in fact I have a tracking ticket for base syscall permission checks:
<braewoods> does Haiku follow unix convention where unlinked files remain available until the last reference is dropped?
<waddlesplash> yes we do!
<braewoods> Ok. I was planning to use that when writing my shared memory code to limit who else can access it to just who I shared the FD with over unix sockets.
<waddlesplash> uh
<waddlesplash> you can't share FDs over unix sockets on haiku
<waddlesplash> we don't actually support that
<braewoods> You can't? But you have SCM_RIGHTS and all.
<braewoods> The API seemed to exist.
<waddlesplash> we do? hmm wait
<braewoods> src/add-ons/kernel/network/protocols/unix/unix.cpp
<braewoods> // we support only SCM_RIGHTS
<waddlesplash> so we do
<waddlesplash> huh
<waddlesplash> I heard someone saying we didn't and they proposed a new API to supplant this not long ago
<waddlesplash> so this then asks the question, do we handle reference loops here properly?
<waddlesplash> (I'm not seeing that we do)
<braewoods> well, you should use the existing convention for compatibility instead if it exists.
<braewoods> but this feature is used heavily by some things like the X server.
<braewoods> as there's only two ways to share memory. you share the name of the segment or the FD to it.
<waddlesplash> we have a third
<waddlesplash> you share the area's ID and make it cloneable
<waddlesplash> (all virtual memory regions on Haiku are "area"s -- yes, everything; mmap or otherwise.)
<braewoods> I see. I may have to just use more platform specific code for the Haiku port once I get around to finishing the unix side.
<braewoods> I was planning to use shared memory to reduce copies of large blocks of image data.
mmu_man has quit [Ping timeout: 480 seconds]
<x512[m]> braewoods: Memory FDs are also supported by Haiku.
<x512[m]> Memory FD can be created with shm_open POSIX call.
<waddlesplash> yes, you can use memory FDs
<waddlesplash> "area"s are just the native API, but there's no reason you have to use that
<braewoods> x512[m]: ok. i was just wondering if it would still work properly when shared via SCM_RIGHTS and the original file was unlinked, having only FDs to access it.
<x512[m]> Yes, it should work.
<braewoods> shm_open on Haiku appears to be implemented the same way as on Linux. a special ram backed FS is used.
<braewoods> but seems like /proc and /sys are mostly Linuxisms. only /dev seems consistent at all.
<braewoods> I was comparing different POSIX implementations. Kinda interesting how much things can vary.
<braewoods> waddlesplash: does Haiku leverage the x86 MMU at all? I would assume so but given some of the designs I kinda wonder.
<waddlesplash> ????
<waddlesplash> of course we do?
<waddlesplash> everything leverages the MMU, you can't *not* leverage the MMU
<waddlesplash> unless you are running DOS or something
<braewoods> Sorry, stupid question I guess. lol... I still remember the days of using Win 9x.
* braewoods winces.
<waddlesplash> lol
<waddlesplash> anyway, yes, Haiku isn't AROS or something
<waddlesplash> we are fully POSIX, we have per-process address spaces, memory protection, ...
<braewoods> Ok, so there's the usual memory protection.
<x512[m]> About multiuser: found some bug about hardcoding USER env var:
<x512[m]> I actually managed to run another user with it own home directory with test_app_server.
<braewoods> Is there actually any proprietary BeOS software that still matters? I've been wondering how valuable compatibility with them is today.
<x512[m]> But for regular boot setting home directory do not work because of hardcoding.
<braewoods> Given how old BeOS is now, I've been wondering how relevant that feature is.
<waddlesplash> there's still some, not a lot
<waddlesplash> the x64 version isn't compatibile with BeOS at all
<waddlesplash> and we've dropped compat from certain areas, like drivers for instance
<braewoods> Understandable but kinda have to move on if you want Haiku to be somewhat usable today.
<waddlesplash> why?
<braewoods> CPU compatibility I guess.
<waddlesplash> we already did...
<braewoods> Yea.
<waddlesplash> you can use AVX2 on Haiku
<waddlesplash> and BeOS applications, at the same time
<waddlesplash> I run Haiku on my Ryzen desktop with an NVMe boot drive, works great
<braewoods> Really... I thought OpenGL and the like wouldn't work with someone that new on haiku.
<braewoods> something*
<x512[m]> The biggest problem with BeOS compatibility is that GCC fundamentally broke C++ ABI in GCC 3, but BeOS used GCC 2.
<waddlesplash> yes
<waddlesplash> so, we have 2 compilers on 32-bit x86
<braewoods> So Haiku doesn't use x86's 32 bit compatibility mode in 64 bit mode?
<waddlesplash> braewoods: we don't have GPU acceleration drivers yet, except for one single generation of Radeon chips from x512
<waddlesplash> braewoods: unfortunately not, yet. there's patches to implement that, partially
<waddlesplash> the x64 version of haiku only supports x64 binaries at present
<x512[m]> Fun detail is that BeOS R3 used PE executables and MS C++ ABI so it may be possible to have compatibility with BeOS R3 applications by using modern Clang with MS ABI support.
<braewoods> It's a mess to do multiarch.
<braewoods> I've seen different uses of that x86 feature on Linux. Most people use the multilib approach.
<braewoods> Meaning that libraries get their own architecture specific locations and the like.
<braewoods> But if Haiku got multilib or something equivalent, it would make 32 bit only Haiku less important I would think.
<braewoods> That said it's probably a complex thing to get working. I don't even know how Linux manages mixing the two.
<x512[m]> The problem is not multilib, the problem is 32 -> 64 syscall translation and 32-64 bit mode switching.
<waddlesplash> we already have multilib
<braewoods> Oh.
<waddlesplash> 32-bit Haiku is multilib gcc2/gcc4+
<braewoods> Interesting none the less... I remember reading about issues related to GCC4 transition when I did distribution work a long time ago.
<braewoods> Not sure what they changed.
<waddlesplash> it appears the usb_disk driver reports something useful for B_GET_DEVICE_NAME
<waddlesplash> so, we can likely make the usb_serial driver do the same
<waddlesplash> that will likely solve the use-case you want
<x512[m]> GCC completely changed C++ ABI. So shared libraries that expose C++ API can't be used with newer compiler.
<braewoods> Ah, right. That's probably why some of the hardcore C programmers I used to talk to hated C++, the whole mess namemangling can create, or used to anyway.
<x512[m]> Hopefully C++ ABI is never changed after GCC 3.
<braewoods> waddlesplash: huh. well it technically just needs to be enough to find the corresponding device under the regular USB interface so maybe that will suffice.
talos has joined #haiku
<braewoods> waddlesplash: so if I need to write raw USB drivers for Haiku from userspace, the libusb backend isn't very good?
<waddlesplash> it probably needs to be repaired somehow
<waddlesplash> if you know something about libusb internals, maybe you are the person to fix it :-p
<braewoods> What issues are you talking about?
<braewoods> I mean, surely there's some bug reports or something to go off of.
<braewoods> The fact native ports that bypass libusb makes it sound like a flaw in the backend.
<waddlesplash> yes, likely
<braewoods> Or something else that libusb relies on.
<waddlesplash> well, android-file-transfer looks like a good benchmark now
<waddlesplash> since PulkoMandy wrote a native backend that works great
<waddlesplash> but apparently the libusb backend doesn't
<waddlesplash> but as for specifics, PulkoMandy is probably the person to ask
<braewoods> Ok. Where would I find the source?
<braewoods> It doesn't appear to be in the main haiku one.
<waddlesplash> ?
<braewoods> android-file-transfer
<waddlesplash> the haiku backend was upstreamed, as I linked above:
<braewoods> Oh.
floof58 has quit [Remote host closed the connection]
<waddlesplash> the Haiku backend to libusb is also upstream:
<braewoods> Yea, I've seen that.
floof58 has joined #haiku
OscarL has joined #haiku
<Skipp_OSX> check this out: gray background on read-only, white on read-write, switches automatically when you change directories
<waddlesplash> oh, I like that
<zdykstra> That's really nice!
<waddlesplash> Skipp_OSX: we already have something similar for Queuries don't we?
<waddlesplash> is this the same color I guess?
<OscarL> uhhh! /me likes!
<Skipp_OSX> same color yeah
<Skipp_OSX> B_DARKEN_1_TINT, and if you change your DOCUMENT_BACKGROUND_COLOR it will tint that instead, although I gotta figure out perceptual_brightness still
<OscarL> that, and a "Mount" menu item on Disk icon... and I'll owe you a beer or something :-D
<Skipp_OSX> I mean, that's easy I'll put on todo list
<OscarL> awesomo, thanks!
Begasus has joined #haiku
<Begasus> g'morning peeps
Begas_VM has joined #haiku
<Begasus> k, 2 recipes checked without libltdl dependency so far, no issues
<OscarL> Good day Begasus
<Begasus> 'lo OscarL :)
<OscarL> (was busy reading the logs :-P)
<Begasus> np :)
<Begasus> heading out in a bit, checkup at the hospital today
<OscarL> Hopefully they'll give you a clean bill of health!
<Begasus> hmm created the flif recipe myself, not sure why I added the libltdl in there :D
<Begasus> not sure what to expect, so will see OscarL :)
<OscarL> My best wishes, in any case! :-)
<Begasus> Thanks :)
<OscarL> Speaking of logs... Sometimes you find nice things buried in there... like... now I git a "vimrc" that *might* convince me to actually learn som vim.
<Begasus> did some basic vim for dummies years ago, don't know where i stashed it, could be handy :P
<OscarL> looks pretty great, and has autocomplete via /bin/clangd.
<Begasus> for me nano is enough :)
<OscarL> I still need to finish tweaking nano's shortcuts to my taste :-)
<Begasus> I only need Ctrl-x :P
<OscarL> << this is what that vimrc looks like (from irc user glog78)
<Begasus> nice! split screen too :)
<OscarL> and here the file: (I had to do some touch ups to make it work nicer on Haiku's Terminal, but pretty sweet so far).
<OscarL> That working autocomplete for C/C++ might really come in handy for me, since Pe's BeBookFetch and BeHappy extension do not work on Haiku :-D.
<Begasus> Patches welcome :-)
<Begasus> how's progress on lout btw?
<OscarL> unless we can have the original Be Book installed... no hope for BeBookFetch, I'm afraid (the BeBook redesign killed the usefulness of the bookmarks it depended on :-/).
<OscarL> re: lout... lout works fine (albeit I'm might need to patch the makefiles to avoid that extra "/lib" in it's data path)....
<OscarL> on the Pe side.. AxelD's refactoring from 2008 were fine, it was a change from weinhold in 2013 the one that broke it.
<OscarL> I managed to fix parts of it.... logs on terminal shows I'm getting the correct paths to the files you can open from the "Headers" button... but Pe somehow still fails to open them.
<OscarL> And not even a peep on console/syslog... so... I'm a bit lost there :-(
<Begasus> k, heading out, cu later
<OscarL> later!
<PulkoMandy> waddlesplash, braewoods: the issue with libusb is that some operaeions never receive a response from the device. I think it is mainly when reading the device descriptors, which our libusb backend tries to implement on its own instead of using the specialized call to do that. But I found no reason why this wouldn't work
<PulkoMandy> I'm not sure why you would need to access a device both at the usb_serial level and at the raw usb level at the same time? For me it would be either one or the other, what's the reason for needing both?
glog78 has joined #haiku
<PulkoMandy> Some time ago I ported to Haiku but I don't know if this will do color displays
<braewoods> PulkoMandy: It will to a limited extent. lcdproc and lcd4linux are actually what inspired my project but I wanted to work with displays that worked with pixels instead of being limited to characters.
<braewoods> From what I recall digging through lcdproc's source code, it supports graphical displays by basically emulating a conventional character display through custom drawing routines.
freddietilley has joined #haiku
<braewoods> PulkoMandy: To answer your question, that's not quite correct. It was to enable me to do device matching based on the USB backing device. Like VID, PID, various USB strings.
<braewoods> But it's not strictly needed. It's just nice to have. Linux and Mac OS seem to be the only unixlike systems that have any kernel APIs that can be used to do this.
<nekobot> [haiku/haiku] autocommitter pushed 1 commit to master [hrev56942] -
<nekobot> [haiku/haiku] af3dceb2795c - Update translations from Pootle
<braewoods> It would allow me to limit my application to just serial ports that are likely to support the device protocol.
<OscarL> darn... I can't see the "I have files to attach to this ticket" checkbox on Trac (with Web+) :-/
<braewoods> But I understand why this isn't really a common thing. Legacy reasons and all. Serial ports were originally hardwired into the system and it made no difference what the device was beyond its capabilities.
MajorBiscuit has quit [Ping timeout: 480 seconds]
<PulkoMandy> Ok, yes, sounds like a reasonable usecase
<braewoods> A number of serial port libraries do this already, where APIs are known to exist. pyserial and libserialport to name a few.
<braewoods> It could be as simple as providing information about what device nodes are backed by a specific bus device through the existing USB userspace api.
<braewoods> Like, this device is being used by usb_serial and has ports/usb0 as its device node under /dev.
Diver has joined #haiku
kescher has quit [Quit: Bye]
Blendie has joined #haiku
xet7 has joined #haiku
<glog78> is there somewhere a description of how to package software ?
<glog78> specially where to put files like man pages / bash completition files and such ?
<glog78> i did currently locally build ag (the silver searcher) with --prefix=$HOME/config/non-packaged
freddietilley has quit [Quit: WeeChat 3.8]
diver1 has joined #haiku
Diver is now known as Guest12213
diver1 is now known as Diver
<Begasus> Glog78, ag is already ported over to haikuports
<glog78> oh i searched for ag
<glog78> a search with silver found it
Guest12213 has quit [Ping timeout: 480 seconds]
<glog78> my fault
<Begasus> you could try next time with "cmd:ag" :)
<Begasus> works also with pkgman
freddietilley has joined #haiku
<glog78> fzy is the second tool in the list
<glog78> is easy to compile too
<glog78> Begasus thanks for the info with cmd
<glog78> it's in the packages too
<glog78> thank you
<Begasus> best way to add software in the depot is to create a recipe for it
<Begasus> np :)
MajorBiscuit has joined #haiku
Begasus_32 has joined #haiku
Begasus_32 has quit []
diver1 has joined #haiku
Diver is now known as Guest12215
diver1 is now known as Diver
Guest12215 has quit [Ping timeout: 480 seconds]
Begasus_32 has joined #haiku
<Begas_VM> waddlesplash ...
<Begas_VM> checking for lt_dlinit in -lltdl... no
<Begas_VM> configure: error: libltdl not found. See README.
<Begas_VM> at least this fails for guile1
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #haiku
MajorBiscuit has quit []
diver1 has joined #haiku
Diver is now known as Guest12220
diver1 is now known as Diver
Guest12220 has quit [Ping timeout: 480 seconds]
<OscarL> Great... Running a DEBUG=1 build of Pe ended up in a crash report :-D (asser failed, "indx < fLogicalSize" on PTextBuffer:L89).
<OscarL> I certainly understood some of that, yup!
<Begas_VM> heh
<OscarL> I remember Pe used to spam the syslog A LOT back in the day... (complaining about the most simple thing... now I can't get it to spit why it fails to open a file when the path it use clearly exists :-/)
<OscarL> Begas_VM, how the hospital visit went? You're still with us, so that's something :-P
<Begas_VM> need to know which package is affecting gst_plugins ...
<Begas_VM> yep, still here, heart is better but not there yet
<OscarL> baby steps? :-)
<Begas_VM> next week checking if the clob is gone in the heart, if so, then they can go ahead with a little electroshock :)
tuaris has quit [Quit: Leaving.]
<OscarL> spicy!
<Begas_VM> all in all, I'm feeling not that bad as before, so ... progress :)
<OscarL> glad to read that :-)
<Begas_VM> we've all got our issues ;)
<OscarL> oh, indeed we do.
gouchi has joined #haiku
gouchi has quit [Remote host closed the connection]
<OscarL> seeing your pkgman output..
<OscarL> would be nice if we could get a dependency tree of those instead of a plain list :-/
<Begas_VM> yeah, think mpg123 is the issue for gst_plugins_ugly, that should shorten the list
<OscarL> was about to say that (but was trying to run inrecipe first)
<Begas_VM> looking into it's recipe helps too :P
<OscarL> and mpg123 says: libltdl
<Begas_VM> that can be dropped there
<Begas_VM> already checked
<OscarL> (first query I run after a reboot on this 32 bits VM is always REALLY slow)
<OscarL> heh, it has it on REQUIRES, not even on BUILD_REQUIRES :-/
<Begas_VM> list is shorter, but still too long imo
<OscarL> mmm mild earthquake. always fun.
<Begas_VM> jikes
<trungnt2910[m]> Very funny when package_daemon requires app_server with a valid screen to initialize new packages.
Skipp_OSX has quit [Ping timeout: 480 seconds]
<OscarL> Begas_VM: this one was just loud (very low freq, of course), but almost zero shaking. Dogs in the zone went crazy for a bit, thou :-)
<Begas_VM> I can imagine OscarL, they pick up those vibes much harder then we do
<Begas_VM> OscarL, how do you use inrecipe again when I want to see which recipe is using fontforge for example?
<OscarL> "inrecipe fontforge" :-P
* Begas_VM bangs head :)
<OscarL> can get more specific with "inrecipe cmd:fontforge" (or lib: or whatever)
<Begas_VM> lib:libfontforge only gives the fontforge recipe
<OscarL> you can also do "inrecipe font*", for example to broaden the net.
<Begas_VM> produces useless recipes I guess :)
<OscarL> sure.
<OscarL> just mentoning you can use regular grep patterns for search.
<OscarL> trungnt2910[m]: good thing your work on HyClone might motivate to fix such limitations, no?
<trungnt2910[m]> OscarL: I guess if such limitations are real problems on Haiku.
<trungnt2910[m]> Right now HyClone already supports running app_server on boot.
<OscarL> amazing progress you make. seems magic for simpler folks like me :-)
<OscarL> Begas_VM. noticed that mpg123 says: SECONDARY_ARCHs.... "x86_gcc2 x86" :-D
<trungnt2910[m]> OscarL: If I could send the source code to the me of 6 months ago, it would also be magic :)
<trungnt2910[m]> s/be/seem/
<Begas_VM> should be removed yes :)
<Begas_VM> rebuilding redland (probably narrows down the list too)
<x512[m]> <trungnt2910[m]> "Very funny when package_daemon..." <- Haiku is not well tested for non GUI use case.
<x512[m]> It seems there are currently no support of UART terminal for example.
<trungnt2910[m]> <x512[m]> "Haiku is not well tested for non..." <- `ssh`ing from a Haiku instance works just fine.
<trungnt2910[m]> s/from/to/
<OscarL> no way to boot in to /bin/consoled anymore, I guess, right? (still remembering my first Haiku boot on real hardware :-D)
<x512[m]> Yes, but on real hardware Ethernet may be not available. Especially non-x86 boards.
<trungnt2910[m]> What's consoled?
<x512[m]> Isn't consoled still GUI?
<trungnt2910[m]> Starts a session directly on the /dev/console?
<OscarL> It was before app_server, that's what I remember, and I could test my TV/FM card driver that way (the analog sound part at least :-D)
<x512[m]> trungnt2910[m]: Yes.
<x512[m]> But /dev/console is implemented over kernel framebuffer.
<trungnt2910[m]> Yeah I'm aware of that, once I tried `echo Hello > /dev/console` and created a mess on my screen.
AlaskanEmily has quit [Remote host closed the connection]
<trungnt2910[m]> For some reasons /dev/console is available on real Linux but not on WSL1.
<OscarL> Begas_VM : xmlsec might be the one trying to pull down libreoffice.
kescher has joined #haiku
<Begas_VM> LO is also using libltdl OscarL :/
<Begas_VM> had to keep devel:libltdl for xmlsec
<OscarL> double whammy :-D
<Begas_VM> but don't know if it's using the new libtool package for that or the old libtool_libltdl package now ...
<Begas_VM> think I've got about 12 recipes open atm here :)
<Begas_VM> now checking guile
<Begas_VM> err ... my bad, LO isn't using it (that is fixed with xmlsec) :)
Diver has quit [Quit: Leaving.]
TMM has quit [Quit: - Chat comfortably. Anywhere.]
TMM has joined #haiku
Diver has joined #haiku
Diver is now known as Diver
<OscarL> heh.
<OscarL> that last list is shorted than what I see here so.. seems you're making progress. no texmacs, for example.
<OscarL> s/shorted/shorter/
<Begas_VM> something is still pulling out redland, but I can't find the reason it would ..
mmu_man has joined #haiku
<OscarL> lemme check.
<OscarL> liblrdf ?
<Begas_VM> redland should be fixed (hence liblrdf too?)
<OscarL> both redland and liblrdf provide lib:liblrdf ?
<Begas_VM> they do?
<Begas_VM> I don't see a recipe for liblrdf ?
<OscarL> and no conflicts, or replaces.
<OscarL> media-libs/liblrdf
<Begas_VM> conflicts with redland
<OscarL> ahh yes, was looking at the wrong file :-D
<Begas_VM> so that can't be it
<OscarL> libreoffice needs lib:liblrdf
<Begas_VM> liblrdf not installed here
<OscarL> the one from redland?
<Begas_VM> redland is yes
<OscarL> not sure which one is the correct one for LO.
<OscarL> (redland should hav a CONFLICTS too, right?)
<Begas_VM> nope, if liblrdf has a conflict with redland it works both ways
<OscarL> good to know.
<OscarL> from some old gentoo bug... seems LO wants redland's lrdf.
Anarchos has joined #haiku
<Begas_VM> k, revbump for redland and xmlsec is working for LO
<OscarL> heh, centos has even a "libtool-ltdl-devel" package.
<Begas_VM> we had/have them in the libtool_ltdl package :P
<OscarL> and debian surely has a _doc package for each one of them too :-P
<nekobot> [haiku/haiku] pulkomandy pushed 1 commit to master [hrev56943] -
<nekobot> [haiku/haiku] e6a598a2f4a3 - ControlLook: fix clipping
<OscarL> (IIRC, debian loved to split packages into smaller parts, right?)
<Begas_VM> as waddlesplash suggested yesterday, it would be better to have only the static library for libtool, this changes some for other recipes
<Begas_VM> and the static one is now in the base one, so there is only one package now for libtool (at least here) :)
<OscarL> so... no more for anyone, right? I guess that will help notice the places where it wasnt' really needed.
<OscarL> (but surely doesn't sounds fun to test all that. Good thing we have you on board Begasus
<Begas_VM> not there yet :P
<Begas_VM> graphicsmagic also in the list
<Begas_VM> looks better now :)
<OscarL> At some point, I should try to rebuild the VMware driver and shutup that damn "VMware: SHOW_CURSOR" message spamming syslog.
<OscarL> much better Begas_VM!
<Begas_VM> not really :/
<Begas_VM> still tries to install the libltdl package for LO (even wan't to bring in the older redland package) :/
<Begas_VM> this could take a while :)
<Begas_VM> back to redland ...
<Anarchos> Begas_VM what is redland ?
<Begas_VM> a library used by LO Anarchos
<Begas_VM> Initialized empty Git repository in /boot/home/haikuports/dev-db/unixODBC/work-x86-2.3.9/sources/unixODBC-2.3.9/.git/
<Begas_VM> Fetching package for libtool_x86_libltdl == 2.4.6 ...
<Begas_VM> :/
<Begas_VM> back to libtool, that's the one pulling in libtool_ltdl
<Begas_VM> must have missed something there
* Begas_VM feels stupid now :P
<OscarL> meh... I do worse daily :-D
<OscarL> easy to get lost among many recipes.
<Begas_VM> k, that is fixed
<Begas_VM> a bit more and I've seen/looked into them all :)
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #haiku
<Begas_VM> k, redland and unixodbc fine for LO
<Anarchos> i try to make the ocaml development type accept to create an "haiku" os_type, alongside with "win32" and "unix" :)
<Begas_VM> and got it working Anarchos?
<Begas_VM> checking for libltdl ...
<Begas_VM> checking ltdl.h usability... yes
<Begas_VM> checking ltdl.h presence... yes
<Begas_VM> checking for ltdl.h... yes
<Begas_VM> checking for lt_dlinit in -lltdl... yes
<Begas_VM> checking if libltdl package is complete... yes
<Begas_VM> so far looking good
<Habbie> Begas_VM, i did libversionCompat for libtermkey/vis btw
<Begas_VM> skipping x11-libs
<Begas_VM> sec, checking Habbie
<Habbie> no rush
<Habbie> just wanted to make sure you didn't miss it
<Begasus> Habbie, I don't see the change in the PR?
<Begasus> still says: lib:libtermkey$secondaryArchSuffix = $portVersion
<Habbie> lol
<Habbie> sorry
<Begasus> ;)
* Habbie boots haiku
<OscarL> K. Seems the Lout addon for Pe is calling proxy.AddInclude() with the proper filenames, but when you click on one of the include items to open it...
<OscarL> the msg_OpenInclude handler contains garbage instead of the correct path :-/
<Habbie> Begasus, pushed
<Habbie> i remembered to commit, which is something
<Habbie> but then i just left the commit there ;)
<Begasus> IIRC libVersion is not portVersion ;)
<OscarL> false alarm... using the variable how it its supposed to be used yields the correct path up to that point at least... the search for the bug continues...
<Begasus> holy moly, think I've made a mistake there Habbie , there is only a static library there?
<Habbie> i hope not
<Habbie> but that'll have to wait
<Begasus> I'm not seeing a shared one ... (although my mind tells me there was one, otherwise I wouldn't have mentioned libVersion..) :/
<Anarchos> Begas_VM i do my best :)
zard has joined #haiku
<OscarL> "libtermkey$secondaryArchSuffix = $libVersion" shouldn't that be $portVersion?
<Habbie> i was also wondering just now
<OscarL> next line seems fine :-)
<Habbie> i very much welcome comments, i barely know what i'm doing here
<OscarL> (assuming that version matches the SONAME thing)
<Begasus> actually should be libVersionCompat (if there is/was a shared library) instead of libVersion there
<OscarL> ^what Begasus said :-)
<Habbie> please comment on the PR so i don't forget
<Begasus> already did with that comment Habbie , but I'm wondering why I don't see a shared library in the build now ...
<Habbie> ack
<Begasus> see ... I'm going nuts here :D
<Habbie> :)
<Begasus> k, seems to be connected to the change of libtool
<Begasus> with the current one from the depot I get the shared one
* Begasus pokes waddlesplash
<Begasus> added suggestions Habbie :)
<Habbie> thanks!
<Begasus> pretty handy, thanks on that tip! :)
<Habbie> :)
<OscarL> I found a cua-mode.vim, plus Glog78's vimrc... this might actually be usable for me. setting it to "notepad mode", just be really heretic :-D
<OscarL> can't use "set mouse=a" :-/ (doens't plays well with Terminal)
<Begasus> should drop the checks on the libtool depending recipes, something is deffenitly wrong ...
<Begasus_32> provides {
<Begasus_32> libtermkey_x86_devel = 0.22
<Begasus_32> devel:libtermkey_x86 = 1.14.2 compat >= 1
<Begasus_32> }
<Begasus> that looks better Habbie :)
Skipp_OSX has joined #haiku
<OscarL> Finally! Seems Pe's "OpenIncludes" didn't expected absolute paths, and that's why it didn't worked.
<OscarL> (for the Lout's addon, that called AddInclude() with absolute paths)
<OscarL> Sigh... just a 5 lines change (not counting closing braces)... damn thing was driving me nuts.
<Begasus> that makes 2 of us today OscarL :)
<zard> OscarL: Vim also provides an easy mode with `vim -y`. Just beware that Vim is even more difficult to exit in this mode than normal :D
<OscarL> already noticed zard, heheh, that's why I searched for an alternative :-P
<OscarL> would be cool to have YouCompleteMe, but while it works for vim, it crashes gvim right at start :-(
<OscarL> next best thing... this /bin/clangd running with whatever plugin that vimrc from Glog78 is using :-)
<OscarL> oh nice... on gvim I get an "LSP" menu, making things far more discoverable for a dumb dumb like me :-D
<Anarchos> OscarL congrat, i will look to it as soon as it will become available on haikuports
<Habbie> love LSP
<Skipp_OSX> maybe it's just me but why can't the_silver_searcher_x86 be called 'ag' ? would make my life easier if it was. I realize that's the name of the app but I don't care I call it ag
<Anarchos> Habbie i too
<Skipp_OSX> as in `pkgman install ag` instead of `pkgman install the_silver_searcher_x86`
<Habbie> pkgman install cmd:ag
<OscarL> Anarchos: YouCompleteMe has a Draft recipe, but not sure who will find and fix the gvim crash. This other thing I'm using now won't be packaged, as is just "user-config stuff".
<Skipp_OSX> oooooooooo I didn't know you could do that
<Skipp_OSX> ok
<OscarL> (the needed pieces are already on the depot: vim, clang)
<Anarchos> Skipp_OSX there is also a pkgman install lib:XXX syntax
<OscarL> and "devel:xxx"
<Skipp_OSX> What can I say, I'm a creature of Habbie
<Skipp_OSX> but that all sounds very nice
<Habbie> :)
<Begas_VM> Think I'm done with the recipes for static libraries (beside the ones I may have missed) :)
<Begas_VM> libsvn ...
xet7 has quit [Ping timeout: 480 seconds]
hightower2 has joined #haiku
<OscarL> "query -a name=*.a | wc -l" -->> 202 :-/
<OscarL> I might need to do some clean up here :-D
<Begasus> not all need to be removed :)
<Begasus> llvm, qt ... bundles quite some there that need to stay
<OscarL> 149 under /system. Yup, mostly libclangxxx.a
<OscarL> still some from both Pythons and some of its packages (numpy, for example)
<Begasus> those probably are not installed through prepareInstalledDevelLibs
<Begasus> and don't end up in developLibDir :)
<OscarL> yup, either under "vendor-packages", or under "python3.x/config-3.x/"
<OscarL> still got some from SDL here. the rest seems reasonable.
<Begas_VM> yes, the ones from SDL are not the same name as the shared ones
<OscarL> I see. then I'm not that far off... just need to clean up some work dirs :-D
<OscarL> bbiaw
<botifico-c849d97b> [haikuports/haikuports] Begasus pushed 1 commit to master [+0/-0/±1]
<botifico-c849d97b> [haikuports/haikuports] Begasus 8ae7ec3 - subversion, disable static libraries (#8527)
<zard> Is there a way to pause execution of code till an event is received?
<botifico-c849d97b> [haikuports/haikuports] Begasus pushed 1 commit to master [+0/-0/±1]
<botifico-c849d97b> [haikuports/haikuports] Begasus 640e1ae - apr_util, remove static library (#8528)
<Begasus> k, biab
<zard> One method is to use a semaphore, but I would either have to create a semaphore for each event that could be waited on
<zard> or check if the right event has occurred after the semaphore has been released.
<Anarchos> zard poll or select ?
<Anarchos> zard condition variable ?
gouchi has joined #haiku
qwebirc5840 has joined #haiku
<zard> Condition variables look interesting...
<qwebirc5840> I need to enable 'fail_safe_video_mode true' in ~/config/settings/kernel/drivers/kernel on the install media but I can only mount it as read-only, so how do I make the kernel modification?
<waddlesplash> zard: in kernel or userland?
<waddlesplash> qwebirc5840: you can enable this in the bootloader menu
<waddlesplash> (only applies to one boot)
<qwebirc5840> I have Haiku on a 8GB USB disk and need to adjust the video to do the install. OK so when it is booting is there a key combination to press to enter the bootloader. Is it like grub and just pressing 'e'?
freddietilley has quit [Quit: WeeChat 3.8]
<zard> userland
gouchi has quit [Quit: Quitte]
<zdykstra> qwebirc5840: are you doing legacy booting, or EFI booting?
<qwebirc5840> Trying it on a old MacBook
<zdykstra> that doesn't really answer the question - but you can either hold shift to access the menu or bang the space bar until you get there, depending on your system
<qwebirc5840> I believe that all intel Mac are EFI
<zdykstra> then you can enable 'Use fail-safe graphics driver' for the purpose of the install and then modify the file you listed previously
mmu_man has quit [Ping timeout: 480 seconds]
<zdykstra> huh, going back as far as the core2duo era of MacBooks, they are EFI. That's mildly surprising.
<zdykstra> so repeatedly hitting the space bar is your menu access method
<Skipp_OSX> how is that mildly surprising?
<Skipp_OSX> Apple never shipped a machine with a regular PC BIOS, and the earliest Intel Macs from 2006 were the first core series so there should be no surprise.
<zdykstra> because I wasn't expecting that? Hence, 'mildly surprising'.
<Skipp_OSX> the early Macs did have a 32-bit EFI which was a bit quirky tho
<Skipp_OSX> early /Intel/ Macs I mean
<puck_> i think that was efi 1 as well?
<puck_> even while they're efi, most of them run windows/bootcamp under CSM
<qwebirc5840> Well just tried shift and spacebar and neither got me into the boot loader, I guess no Haiku on this old hardware back to Ubuntu. Thanks, will continue playing with Haiku in VMs and maybe someday get real hardware that I can put it on.
<zdykstra> did you repeatedly hit spacebar? It might take a few tries.
<Skipp_OSX> hold spacebar
<Skipp_OSX> it's tricky to do sometimes so I can't blame you for having trouble
<qwebirc5840> tried holding shift, tried holding spacebar and tried repeatedly hitting spacebar
<Skipp_OSX> you gotta wait until after the bios loads but before the OS boots you have a narrow window there to hold spacebar in
<Skipp_OSX> is Ubuntu still Unity or did they ditch that?
<qwebirc5840> Yeah I know it is a short window, tried all combinations multiple times and nothing. I am even trying my BeOS 5 CD and it just stops at the loading screen between the PCI card and the lightning bolt.
<OscarL> Can't mount the usb install media on a a Haiku VM, and edit the vesa file that way?
<qwebirc5840> I'll give that a try
<Skipp_OSX> hmmm BeOS doesn't even get the memory count before giving up
<Skipp_OSX> mmmm or maybe it does, I'm not sure which icon is the memory count on BeOS
<Skipp_OSX> lemme check... yep pci card icon is memory count, it's expected to fail there if you have > 768MB of RAM
<Skipp_OSX> which of course you do, as that's a tiny amount of RAM these days
<qwebirc5840> yeah 4GB of RAM in this 2007 MacBook
<Skipp_OSX> WAY too much for BeOS R5
<Skipp_OSX> you might be able to patch the boot-loader but I haven't managed to get that to work yet
<OscarL> Using a prepatched "distro" like BeOSMaxEdition might help
<qwebirc5840> Going to try Haiku VM mounting the USB stick and see if I can modify the ~/config/settings/kernel/drivers/kernel to use the fail-safe video mode
<OscarL> you can even boot that install media on a VM, and just edit the file there.
<OscarL> then on real hardware it will boot in Desktop mode, and you can open the Installer from Deskbar.
<zdykstra> good idea
<Anarchos> Skipp_OSX i remember an option in haiku_loader to limit the memory to 4Gb ?
<Skipp_OSX> yep
xet7 has joined #haiku
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<zard> <Skipp_OSX> "is Ubuntu still Unity..." <- No, I believe they use Gnome by default now.
<Skipp_OSX> ah much better
<botifico-c849d97b> [haikuports/haikuports] diversys pushed 1 commit to master [+2/-2/±0]
<botifico-c849d97b> [haikuports/haikuports] davidkaroly 29a02f1 - tcpdump: update to 4.99.4 (#8529)
HaikuUser has joined #haiku
<HaikuUser> hello
<waddlesplash> hello
<HaikuUser> are you human&
<HaikuUser> ?
<waddlesplash> last I checked, yes :)
<HaikuUser> cool :D
<HaikuUser> btw how to change nickname&
<HaikuUser> ?
<waddlesplash> use /nick command
<HaikuUser> thx
HaikuUser is now known as Inklime
<Inklime> feelin' good!
<waddlesplash> :)
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
* OscarL wonders if Inklime is really a human... kinda sus :-P
<Inklime> sussy baka
<OscarL> (thanks heavens for "know your meme")
bbjimmy has joined #haiku
<Inklime> Hi
<nekobot> [haiku/haiku] waddlesplash pushed 1 commit to master [hrev56944] -
<nekobot> [haiku/haiku] c7cd1bae689d - BeControlLook: fix clipping rect, part of #12890
Inklime has quit [Ping timeout: 480 seconds]
<OscarL> On PulkoMandy asked for someone to "rebuild the repository" so that change can be merged. Do we need to CC someone in particular? (or perhaps it is just something low prio)
<PulkoMandy> I can probably do it, just didn't have time
<PulkoMandy> Waddlesplash or kallisti5 also could
BrunoSpr has joined #haiku
<OscarL> ah, np! just wondering.
tuaris has joined #haiku
<glog78> damm v lang has troubles with termio
<glog78> :(
<glog78> i am still searching for one of the modern languages to play around
<glog78> rust -> rust-analyzer seems to have problem (can't say if vim9-lsp or the lsp server)
<glog78> btw how many hugs do i need to spend to get a newer version of vim ? ... some kinda nice features like virtual text are missing in the current version
<BrunoSpr> hello all... Where to find the /tmp folder?
<glog78> vlang -> doesn't compile even it at one time did after commenting out an include according to a github thread i found
<glog78> go -> is totally outdated on haiku
<glog78> the idea is ... all of those languages have great and easy to use libraries for networking / json and stuff
<glog78> a big plus with so much stuff which is only happening online nowadays
<Begasus> BrunoSpr, /var/tmp ?
<Begasus> waddlesplash, looks like we need to keep the shared library for libtool, you probably saw the logs from earlier
<BrunoSpr> ah Begasus... thanks...
<OscarL> Glog78, I've updated the vim recipe recently to the latest vim version, but didn't touched the features it is build with (as I'm not much of a vim user).
<OscarL> you may want to open an issue over haikuports listing the features you think we should enable (assuming they work ok on Haiku :-D).
<Begas_VM> Glog78, you could add an issue for missing features ...
<Begas_VM> OscarL beats me ;)
<OscarL> yes! :-P
<Begas_VM> parse errors for libdvdread (gcc2)
<glog78> OscarL started to feel more and more love for vim (to be more exactly neovim) like one year ago. And since a while i think once you get into it that it is as powerfull as visual studio code with being much more customisable than visual studio code in terms of resources and what is enabled at a certain time
<glog78> is it for everyone no -> because you need to want to take your time to make vim / neovim yours. Once you do ... it's just a rabbit hole
<glog78> @Begas_VM on the official bug tracker ?
<waddlesplash> for vim, on the haikuports bug tracker
<waddlesplash> Begasus: all those errors have solutions, but, due to korli's comments I think keeping it does make more sense after all, indeed
<glog78> thank you guys :) github i am in for it :)
<OscarL> my main issue with vim and the like, is that they seem (to me at least) assume the user is an English native speaker... so "remembering" commands comes more naturally.
<Begas_VM> less hastle to fix the current ones still using the shared ones, for those that don't need they can be removed (mpg123 and flif don't use it for instance)
<OscarL> that's why I tend to favor cua-key-bindings (easier for my muscle memory, and no "translation" involved :-D)
BrunoSpr has quit [Quit: Vision[]: Ich wurde gewaschen!]
BrunoSpr has joined #haiku
<glog78> OscarL yeah the defaults sometime sucks , good you can remap everything. But in the end vim's way of editing text is different from what i was used before. After slowly getting into i am now as fast as i would most likely be with a "regular" editor but i know that i should improve much more if i would dive deeper into all the shortcuts and put them in a way comfortable for me
<botifico-c849d97b> [haikuports/haikuports] Begasus pushed 1 commit to master [+0/-0/±1]
<botifico-c849d97b> [haikuports/haikuports] Begasus 28f1795 - sge, remove static library (#8531)
<glog78> << i hope this is all the infos you guys need ?
Begasus_32 has quit [Quit: Vision[]: Gone to the dogs!]
<Begasus> OscarL, will have a look at it ;)
<Begas_VM> 17 static ones in /boot/system/develop/lib :)
<Begas_VM> when the one from libtool is gone 16 (those should be ok)
<OscarL> damn! vim devs have really embraced the "release earlier, release often" :-D
<Begas_VM> had that with texsturio once, new release pushed and the next day they released a new version :P
<BrunoSpr> Begasus... need some help: Can you manage to find the USB descriptors for the mouse? They should be in /tmp when the system is booted. PulkoMandy wrote... How to get these descriptors.. very confusing because I have no /tmp file in there...
<Begas_VM> no idea there BrunoSpr, sorry
<glog78> they needed to change considering neovim is a highly active project and in a way neovim and vim fighting for the same people
<OscarL> if that feature was added in 2022-09-10, shouldn't that be already available in our version Glog78? (it is only 4 days old :-P)
Begas_VM has quit [Quit: Vision[]: i've been blurred!]
<glog78> VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Apr 23 2023 14:28:55) << i could download is from 28 Jun
<glog78> (vim --version)
<Begasus> k, done for today, cu peeps!
Begasus has quit [Quit: Leaving]
<glog78> Begasus thank you alot
<glog78> i am 99% out of luck with termios and vlang i guess
<OscarL> vim 9.0 might have been released on Jun 2022, but 9.0.1479 is from 4 days ago.
BrunoSpr has quit [Quit: Vision[]: Ich wurde gewaschen!]
<glog78> that would be crazy
<OscarL> vim released twice today only :-D (9.0.1489 and 9.0.90)
<OscarL> See for yourself:
<glog78> check
<glog78> << see NEWS -> 9.0.1490 is current according to their website
<OscarL> can't access from here :-/
<OscarL> anyway... we get the sources for vim from github... and that is pretty definitive.
<Skipp_OSX> you have to go to (not https)
<glog78> or ->
<Skipp_OSX> I see there's a link at the top that says that
<glog78> btw now its 9.9.1491
<glog78> btw now its 9.0.1491
<glog78> rofl
<glog78> but it should be available since 2022-09-10
<OscarL> Skipp_OSX, yeah, that worked (adding the www.)
<glog78> so maybe we really need to add a feature enable for that
<OscarL> that's what I was after.
<glog78> but there is nothing in the documentation
<Skipp_OSX> I see how it is, I can't talk pol here but you all post websites with Ukro flags on them
<glog78> let me check something
<OscarL> welcome to the world of software packaging!
<Skipp_OSX> ( too, bah)
<OscarL> there's a difference between sharing a link to a site I don't have control over, that may have unrelated stuff to my main insterest, and just doing that offtopic myself.
<waddlesplash> yeah, exactly
<Skipp_OSX> ok fair
<waddlesplash> and people can get as off topic as they want in #haiku-offtopic
<waddlesplash> (so log as things stay civil)
<glog78> OscarL: -> << according to the lsp plugin virtual textt das not exist
<OscarL> will see if I find a relevant flag to enable tomorrow.
<glog78> according to the plugin it needs -> 9.0.1157 or later
<glog78> so it should be there even with your build from yesterday :thinking:
<OscarL> still need to test, pass the review process, get merged, and built on the buildmasters... ain't instantaneous :-D
* OscarL "English" is gentting worse by the hour.
<OscarL> *getting, damn it.
<glog78> OscarL gvim on haiku means vim compiled against be framework do i understand correctly ?
<OscarL> I assume so, but I haven't delved much into that (this was my first time touching vim, usually it got updated by other folks).
<glog78> oh i see
<glog78> i give made props already to this project that they notice haiku as supported
<glog78> both (terminal mode and gfx mode)
<OscarL> "set mouse=a" seems utterly broken (at least when using Haiku's Terminal from VBox with "USB Tablet" style pointing device).
<glog78> it might be an issue with the terminal
<glog78> but i am unsure
<OscarL> our Terminal has some quirks, yeah.
<glog78> vim --version shows that mouse is only supported on urxvt , netterm and sgr
<glog78> the terminal exports xterm-256color
<glog78> so my guess is that the mouse support in the terminal is not 100% compatible with the original xterm
<glog78> i switched yesterday to my terminfo for contour and since that time mouse support on vim is disabled
zard has quit [Quit: leaving]
<glog78> with xterm-256color the mouse works fine in my terminal but i have other issues i don't like
<glog78> anyway i need a test for virtual text outside of the plugin
<glog78> maybe the plugin is buggy and there is no need for a new version
<OscarL> I can't find much about that "virtual-text" thing on vim's docs (and on our "vim --version" the closest match is "+virtualedit").
<OscarL> maybe is something you can set in the vimrc?
<OscarL> (I have zero idea bout vim, as you can see :-P)
HaikuUser has joined #haiku
<HaikuUser> test
<OscarL> pass
HaikuUser has quit []
<OscarL> that was quick.
<glog78> OscarL in this case we close the request till i can test everything against a linux build
<glog78> we can't exclude a plugin error but i don't know any other way out of my head how to check for virtual text easy
<OscarL> no harm in leaving it open for now (closing and reopening will generate more noise, I guess).
<glog78> or this way
<glog78> I am already happy to have a working lsp implementation including the possibility to configure the lsp servers ourself
<glog78> so we should be able to use nearly every lsp server we can get running on haiku
<glog78> like i might check for the bash language server
<waddlesplash> now this is going to be a fun one to try and fix
<OscarL> I've tried with YouCompleteMe and Python files, worked well, but again, only on vim (seg-faults gvim, some bad interaction there)
<waddlesplash> (in fact, it was already a fun one to find the cause of in the first place, I ran into it multiple times before without real luck in tracking it down, before last summer's modifications)
<OscarL> meanwhile I get bamboozled by some missing semicolon :-D
<glog78> waddlesplash: congratz this is a hard one to track down
<OscarL> guess some of us need to fill up the rest of the bell curve :-P
<Skipp_OSX> syntax errors are easy, deadlocks are hard
<OscarL> ^ now I underestood my own joke, thanks!
<glog78> why do tools complain about not be able to symlink but i an do a ln -s ?
<glog78> i can do ...
<Habbie> symlink or hardlink?
<waddlesplash> there are no hardlinks on BFS, yes
<waddlesplash> there are symlinks
<waddlesplash> so an "ln" without "-s" won't work, indeed
<Habbie> i noticed, yesterday, incidentally
<Habbie> or a few days ago, when a backup from haiku to a linux system somehow doubled in size
<glog78> symlink as far as i see
<Habbie> haven't figured out why yet
<waddlesplash> (if you mount an ext4 partition or some other FS that does support hardlinks, it will work there just fine. it's just BFS that doesn't support hardlinks, not Haiku)
<glog78> << here is an example
<OscarL> you can't write anything on RO fs.
<zdykstra> Habbie: here's my super awful backup script -
<glog78> also npm is another tool which is "outdated" or to be more exactly the node which npm uses
<zdykstra> mounts a bfs image, rsyncs to it, then rsyncs the image to a remote server where it gets into my ZFS snapshot rotation
<glog78> OscarL this happened when i tried to use npm install
hightower2 has quit [Ping timeout: 480 seconds]
qwebirc5840 has quit [Quit: [Thanks for the help]]
<waddlesplash> yeah we need to update node
<waddlesplash> jessicah was working on that but ran into some bugs in Haiku
<waddlesplash> I was actually meaning to look at those bugs this week
<Habbie> zdykstra, why not mkdir -p instead of test || ?
<glog78> I really don't want to stress anyone !
<Skipp_OSX> APFS also doesn't support directory hard links, and the reason is the same as BFS, Dominic Giampaolo
<zdykstra> Habbie: 6 of one, I guess
<glog78> Just writting down what i notice trying to setup haiku a little further than only the desktop
<Habbie> zdykstra, trade you for half a dozen
<zdykstra> deal!
<glog78> in this case it was installing bash-language-server
jmairboeck has joined #haiku
<Habbie> zdykstra, ah, an image, clever
<zdykstra> it's funny having a bandwidth replicant on my desktop. Every key press in my IRC client (weechat over ssh) causes little spikes in the graph.
<Habbie> haha
<Habbie> the per-keypress overhead for that mode of operation is huge
<zdykstra> I made a 10GB image, worked pretty well. But I rely on ZFS snapshots to actually keep old data for me. So the image file only ever holds the most current copy of things.
<Habbie> right
<Habbie> i stick most things into restic, but i think it's not in haikuports yet
* zdykstra googles
* glog78 googles too
* augiedoggie altavistas
<zdykstra> crashes WebPositive
<Habbie> ouch
<Habbie> anyway, it's remote backup, encrypted, with dedup
<Habbie> (or local, if you want)
<zdykstra> nice
<Habbie> yes, i'm a big fan
<zdykstra> the Mac client would be nice for my wifes laptop
<botifico-c849d97b> [haikuports/haikuports] diversys pushed 1 commit to master [+3/-3/±0]
<zdykstra> do you know how well it works there?
<glog78> oh nice tool
<botifico-c849d97b> [haikuports/haikuports] davidkaroly 422860e - iperf3: update to 3.13 (#8532)
<Habbie> zdykstra, as far as i know it works fine on mac
<glog78> those "new" languages bring out alot of crazy interesting tools
<OscarL> re: altavista... wasn't there for a while an "hastalavista" search engine around those years... that was for warez stuff?
<augiedoggie> heh, doesn't sound familiar
<glog78> OscarL: you might be right
<OscarL> circa 1998-2000
<Habbie> i remember something like that, but this feels offtopic
<OscarL> augiedoggie's fault! :-P /me goes back to the Basser Lout recipe.
hightower2 has joined #haiku
<nekobot> [haiku/haiku] waddlesplash pushed 3 commits to master [hrev56945] -
<nekobot> [haiku/haiku] f5e531e92e42 - kernel/thread_types: Remove Thread::condition_variable_entry.
<nekobot> [haiku/haiku] 557f0446b318 - kernel: Introduce THREAD_BLOCK_TYPE_OTHER_OBJECT.
<nekobot> [haiku/haiku] 484bf053dc67 - VMCache: Use THREAD_BLOCK_TYPE_OTHER_OBJECT.
<Skipp_OSX> node is trying to write to a read-only packagefs directory, not a hard link issue
<Skipp_OSX> node_modules/ directory needs to be put somewhere else (in the package config)
<glog78> may i ask a design question ?
HaikuUser has joined #haiku
HaikuUser has quit []
<Skipp_OSX> sure
<glog78> why not makeing a virtual filesystem which contains the "unix" structure
<glog78> this "unix" structure is "writeable" and typical unix ports gets installed with this directory as prefix
jmairboeck has quit [Quit: Konversation terminated!]
<Habbie> what problem are we solving?
<glog78> this could reduce the porting overhead to adapt every package on the filesystem structure of beos
<glog78> like for example right now npm
<glog78> or i used make install which installed man files to $PREFIX/usr/share ...
<glog78> and and and
<glog78> also this structure could hold interopt libraries so you could update this side independendly from loosing compatibility with beos
<glog78> it's just something which got on my mind with my very limited experience
<Skipp_OSX> Well first of all we don't want the unix directories because we don't like them, ok well some people don't like the way they clutter up the root of the fs. Secondly, we have decided to create packagefs virtual file system that merges in directories from packages with non-packaged directories into read-only file system. Basically we created this problem for package maintainers on purpose because of how we designed our package system.
<Skipp_OSX> I'm not sure why we call it "non-packaged" instead of the more canonical "unpackaged" would have made more sense and not used a -
<glog78> i could imagine so much
<Skipp_OSX> but that's a whole other story
<glog78> so i did ./configure --prefix=$HOME/config/non-packaged
<OscarL> doesn't "unpackaged" implies/suggest (or can be read as) that it was packaged and then un-packaged? while non-packaged is... well... that.
<OscarL> like... unzipped vs non-zipped.
<glog78> and while the files in $HOME/config/non-packaged/bin was in path and could be used
<Skipp_OSX> I guess so
<OscarL> Might be my poor English, thou.
<Skipp_OSX> your English isn't so bad, that must be the thinking
<glog78> the man files in $HOME/config/non-packaged/usr..... where not found by man
<Habbie> man or man -k?
<glog78> man
<glog78> maybe something is even missing on my side
<OscarL> mandoc has problems with man page from packages installed in HOME, at least.
<OscarL> (pkgman install -H <package_with_manpages>)
<glog78> and i could have easily merged this one directory with /boot/system/documenation/man/ where i guess they belong to
<OscarL> (then man complains everytime you use man after that)
<glog78> OscarL i did ./configure | compile myself
<Habbie> from my notes: after installing my wdiff package, man wdiff works but mentions man: outdated mandoc.db lacks wdiff(1) entry, run makewhatis /boot/system/documentation/man. Running that makes the message go away, but should this be automated?
<Habbie> :)
<glog78> yeah Habbie that works for /boot/system/documentation/man
<OscarL> Habbie remembers, I see.
<glog78> i have seen this a few times when installing packages
<glog78> with pkgman
<OscarL> seems like a bug on our man port.
novaphoenix has quit [Quit: - Chat comfortably. Anywhere.]
<Habbie> OscarL, maybe - do we even have triggers (like Debian does) for a port to tell another port "i got into your stuff, please see it"?
<Habbie> (i mean, if we don't, it's still a bug, it just starts outside the man port)
<OscarL> I think I have it already on my "Things to check if I can try to fix someday" list.
phoenix has joined #haiku
<Habbie> hehe
<Habbie> that's this list too
<Habbie> (it's very big)
<glog78> and sorry if i asked stupid questions
<glog78> but while i found alot of documentation towards the api and the desktop usage , the documentation for the command line is very little
<glog78> or for the packaging (at least what i found so far)
<OscarL> we are all l33t h4xors! no need for docs!
<glog78> OscarL ... i would be happy to be able to call myself intermediate pc user i am far from what i call a h4xor
<Habbie> i know you're joking but it's always a real problem
<glog78> like another example i run into with my first installation
phoenix has quit []
<OscarL> Glog78, I'm of course, just kidding. More likely becase the team is really small, and there's so much that people can do.
<glog78> ssh-copy-id does connect to $HOME but after creates the keys in $HOME/.ssh
<Habbie> oh, i hadn't even tried ssh-copy-id, but there are more problems there
<glog78> the default config in haiku expect the files in /boot/system/settings/ssh/
<Habbie> man ssh_config does not know that
<Habbie> but i don't think fixing that will fix ssh-copy-id ;)
<glog78> wrong path
<OscarL> This OS feels like a restaurant with really tasty food, but if you miss a glass or a fork, or some ketchup... be prepared to help yourself :-D
<Habbie> yeah, ssh-copy-id can't know that
<Habbie> the way it is currently written
<glog78> $HOME/config/settings/ssh/authorized_keys is the right file
<glog78> there are multiple ways to handle this
<glog78> but this is making configuring ssh for average user nearly impossible when it comes to a more secure way
<glog78> and every security specialist suggest you to not use username/password anymore specially since the username is fixed in haiku's case (aka default = user in prebuild installation images)
phoenix has joined #haiku
<Habbie> to be fair, haiku has zero security focus anyway
<Habbie> the only user is root
<Habbie> that said, making remote access secure would be the first step
<Habbie> and it would be nice if ssh was easier to configure and if ssh-copy-id worked
<Habbie> making sshd easier to set up should not be hard; making copy-id work feels a bit more complicated
<glog78> << if enabling ftp and telnet as easy as one click and works after
<glog78> and ssh which should be used instead of both other needs to change a file
<Habbie> indeed, it should be that easy, and it can be
mattlacey has joined #haiku
<Habbie> just isn't now
<glog78> and even than is not as easy to make secure ... average users might use what works
<glog78> a workaround could be a default symlink
<Habbie> i thought about that too but it would hide bugs in software that uses the wrong path
<glog78> yeah but i guess in the end you won't get around to accept $HOME/.ssh being the user directory for ssh
<glog78> every external tool expect it to be there
<Habbie> every? or just one?
<glog78> good question
<glog78> but this one is used in many user guides
<Habbie> can't deny that
<glog78> also even if that is fixed .. it doesn't fix the issue with how to first upload the certificate
<glog78> even that could be included in the installer
<glog78> like hey if you want to login using ssh please copy now your public key or select your public key
B2IA has quit [Quit: Vision[]: i've been blurred!]
<glog78> if a key is uploaded during installation you could enable ssh easy
<Habbie> the installer, currently, is a terrible place for that
<Habbie> well, no, take that back
<Habbie> whatever you get when you boot your usb stick the -first- time is a bad place for that
B2IA has joined #haiku
<glog78> since you can mount other filesystems during installation (even currently only throu the partition program) you could just mount an other usb device with the pub key (advanced user)
<glog78> and i am just spinning ideas right now
<glog78> the big question is how to get the pub key very easy into the system for the users
OscarL has quit [Quit: Nettalk6 -]
<Habbie> raspberry pi os could inspire
<glog78> i never played with a raspberry pi
<Habbie> pi os is 'installed' by just imaging to an SD
TkTech has joined #haiku
<Habbie> and you can put a few files on the SD afterwards, to enable ssh, to set a password, to load an ssh key, to configure wifi
OscarL has joined #haiku
<glog78> yeah but bfs might make this complicated cause for example windows can't read bfs out of the box
<Habbie> on the pi, the SD has a FAT partition and an ext4 partition
<Habbie> the FAT partition is there for other reasons, but it's convenient for this purpose too
<glog78> yeah something like this would be cool but is troublesome in virtual environments
<Habbie> while i get you're just spinning ideas, you can't shoot down every idea because there is a situation where it might not work :)
<glog78> isn't currently the main userbase using haiku in a virtual machine ?
<glog78> that's why it did come directly to me
<Habbie> i don't know
<Habbie> if they do: i don't see that ssh is a big problem
<Habbie> if they don't: they can put files on the install image
<Habbie> (none of my Haiku installs are virtual)
<glog78> i guess so
<zdykstra> I was only half paying attention - what specific problem are you trying to solve?
<glog78> << this is ok for a beta but it's insecure
<glog78> basically from a security point you don't want to have a username / password login where the username is also known
<glog78> so we were discussing how to make it convinient if not easy for people to enable ssh
<glog78> we did come up with this topic because ssh-copy-id (which is used in many guides) won't work on haiku out of the box
<Habbie> the question i have right now is, where is the right place to write these concerns?
<Habbie> trac?
<Habbie> (i don't agree on all of your concerns, but i do agree on some of them)
<zdykstra> curl -o ~/config/settings/ssh/authorized_keys<username>.keys
<glog78> and Habbie also gave a valid reason why $HOME/.ssh shouldn't be default to satisfy ssh-copy-id
<glog78> zdykstra good idea
<glog78> getting the keys from a web resource
<zdykstra> I'd agree that in general, you shouldn't allow password logins - especially for root
<mbrumbelow> waddlesplash: You know why I love the Haiku community so much?
<Habbie> zdykstra, which is the only user haiku has :)
<zdykstra> (by default)
<zdykstra> you can add more users
<Habbie> well, would they have fewer permissions?
<zdykstra> don't use logic on me, sir
<Habbie> no logic at home, no logic on #haiku.. then where ;)
<waddlesplash> mbrumbelow: ?
<mbrumbelow> More drama than a Shakespeare's play... :)
<waddlesplash> lol
<zdykstra> where is there drama?
<Habbie> zdykstra, different people have different bars for drama
<Habbie> some low, some lower
<zdykstra> until people are getting k-lined or kick-banned, it's not drama
<zdykstra> it's just Sparkling Discussion
<mbrumbelow> Every place I go... forums, IRC Channels, etc... and you know what... I love it.
<glog78> is there a easy way how to maybe submit a new netservices guide to review and work on together ?
<zdykstra> development looks to be done through
<mbrumbelow> waddlesplash: BTW, good article and widely linked to as well.
<waddlesplash> Glog78: yes, PRs are accepted to website github repo
<waddlesplash> expect some bikeshedding on this though :p
<waddlesplash> mbrumbelow: "widely linked to"? well, there was HN, reddit, etc.
<waddlesplash> not sure if that's "wide"
<zdykstra> osnews linked it
<waddlesplash> right
<zdykstra> they're in the tens of visitors per month
<OscarL> lol
<zdykstra> I say that with love - I've been a regular to that site for 20 years now :)
<glog78> waddlesplash i don't want to change the content to much , maybe add a warning and reorganize the section about ssh
<OscarL> still remember Tom's comic periiod?
TkTech has quit [Quit: The Lounge -]
<zdykstra> I don't remember that
<Habbie> Glog78, then submit your change
<zdykstra> should I, or should I leave it blocked out?
TkTech has joined #haiku
<glog78> yeah i hope to be able to do this during the weekend
<glog78> or maybe earlier
<OscarL> "Focus Shift". The one with the WTF/s was nice at least :-)
<mbrumbelow> A friend reached out to me about the link on Y Combinator. Wanted to know what I thought about it.
<OscarL> heh, and I keep misspelling Thom's name still.
mmu_man has joined #haiku
<Skipp_OSX> I don't because of WoT
<Skipp_OSX> (Rand's step-father is Thom)
<Skipp_OSX> and also Thom Merrilyn
<zdykstra> It's Tam in the English version
<Skipp_OSX> interesting... I didn't know that
<zdykstra> Tam al'Thor
<zdykstra> which language did you read the series in? I have a German translation of the first book on a shelf
<Skipp_OSX> US English apparently
<Skipp_OSX> maybe I'm misremembering
<Skipp_OSX> I don't remember Tam, it was Thom
<Skipp_OSX> Thom al'Thor
<zdykstra> the gleeman was Thom
<Skipp_OSX> Thom Merilyn I guess that must be what I was thinking of
<OscarL> (/me had to look up WoT)
<Skipp_OSX> ok it is Tam my mistake
<zdykstra> it's a good series. I'm grateful that Brandon Sanderson stepped in to finish it after Jordan died.
<Skipp_OSX> yep
<OscarL> offtopic! I hear Habbie shout from the background.... /me goes back to lout.
<OscarL> note to self: $dataDir and $docDir are NOT to be mixed up. sigh...
<nekobot> [haiku/haiku] waddlesplash pushed 5 commits to master [hrev56946] -
<nekobot> [haiku/haiku] d8e4f52b7846 - kernel/condition_variable: Add a ConditionVariable::EntriesCount() routine.
<nekobot> [haiku/haiku] 9747721a43cf - kernel/condition_variable: Add a fast-exit from Wait() for negative timeouts.
<nekobot> [haiku/haiku] 6acd708e97ad - xsi_message_queue & xsi_semaphore: Use condition variables to wait.
<nekobot> [haiku/haiku] d8f78afc8af5 - xsi_message_queue: Permit incoming buffer to be NULL.
<nekobot> [haiku/haiku] 8540053c8a90 - xsi_message_queue & xsi_semaphore: Downgrade a lot of traces.
<zdykstra> OscarL: they're only off by a few characters, no biggie
<Habbie> OscarL, i do not mean to be that person
<OscarL> zdykstra: seems I can't see straight at this hour.
<OscarL> Habbie: I intended that to sound playful.
<OscarL> might have failed :-/
<Habbie> ok, good, i was unsure :)
<Habbie> no worries
<waddlesplash> Skipp_OSX: you can retrieve change-ids for changes that don't have them from ... ... the email headers
<waddlesplash> "Show original"/"View source"/etc. -> X-Gerrit-Change-Id
<OscarL> waddlesplash and the newer gerrit shows it on the web page.
<waddlesplash> it does?
<waddlesplash> older gerrit used to
<OscarL> yup.
<waddlesplash> but then they deleted that
<waddlesplash> oh, good
<waddlesplash> maybe we can persuade kallisti5[m] to attempt a gerrit upgrade :)
<OscarL> I mean.. haiku's gerrit does already.
<waddlesplash> it does?
<waddlesplash> where?
<waddlesplash> oh
<waddlesplash> so it does. huh.
<waddlesplash> Skipp_OSX: apparently you can get it from the webpage, too. no email workaround needed
<OscarL> Skipp_OSX: example... (below the commit message).
<OscarL> if the commit message already includes it... then the id below that doesn't shows (makes sense).
<glog78> Q: pkgman install pip -> it says it's installed but -> calling pip says command not found
<OscarL> "pip" (no version) is only installed for Python 3.9
<OscarL> if you installed another version, say pip_python310... then you'll have only "pip3.10"
<waddlesplash> zdykstra: but anyway, I think has more readers than "tens per month"
<waddlesplash> and my citation for thinking so is ... Haiku's own referrer traffic
<waddlesplash> is currently at 400 referrers, and that's of course just people who don't have DNT enabled or other privacy-protecting things that defeat our analytics
<OscarL> "pkgman install pip"... that might be pip for python2 actually :-D
<Habbie> ouch
<OscarL> nah... it is just the generic base package.
<OscarL> that doesn't includes nothing (known defect of all python packages on Haiku)
<Habbie> so, ouch
<Habbie> ack
<OscarL> Glog78. make sure to "pkgman install pip_python39"
<OscarL> that should give you /bin/pip, /bin/pip3 and /bin/pip3.9
<glog78> thank you
<glog78> i have used pip3.10
eroux has quit [Quit: Textual IRC Client:]
<glog78> i want to try if the cmake-language-server work
<OscarL> good choise, as it is the first one where the REPL works with line-editting, history, autocompletion.
<OscarL> *choice
<OscarL> or w/e
<glog78> btw is there an alternative to whereis on haiku ?
<OscarL> this is the issue for the Python packages thing...
mattlacey has quit [Remote host closed the connection]
<OscarL> ("base packages don't provide anything")
<OscarL> which? locate?
<B2IA> (AGMS) Glog78 The "query" command in the CLI and the find files in Tracker.
<OscarL> aliased as "qn=query -a name=" here.
<glog78> thank you both
eroux has joined #haiku
<glog78> OscarL: -> ;)
<nekobot> [haiku/haiku] waddlesplash pushed 1 commit to master [hrev56947] -
<nekobot> [haiku/haiku] 7b3bfaf34fb0 - netfs: Removed 'result' variable
<OscarL> nice :-)
<glog78> OscarL: pip3.10 install cmake-language-server | vimrc ->
<OscarL> very cool. will save that.
<glog78> rust language server starts too | also gives you Outline but doesn't complete correctly currently
<OscarL> I had to disable the rust thing, and the "↵" appears as just an empty rectangle on Haiku's Terminal.
<glog78> outline view = LspOutline
<glog78> if you install rust from repro it is
<OscarL> (eol char.. got mangled here too, so not sure you see) "set list" was also causing issues.
<glog78> eol char = ↵
<OscarL> and the relativenumber thing.... was giving me headaaches :-D
<glog78> needs utf8 enabled font and utf8 enabled terminal
<glog78> the default font on the haiku terminal isn't utf8 ready
<glog78> so yeah you can just change to eol:$
<OscarL> BeOS was utf-8 before it was cool, might try with a different font.
<OscarL> I see a similar char on other editors, Koder, for example, so might be that particular one.
<glog78> i have a terminal with Ligatures support so for coding this is amazing for angband it's better to use NoLigatures
<OscarL> also... the online instructions to installl jetpack fail on Haiku.... curl has problems understanding that it can write in under ~/config/settings/ if you pass it as /boot/system/home/[...]-
<OscarL> (complains about the FS being RO :-D)
<glog78> yeah i noticed this ... i was to lazy to check deeper and just made me a notice where the file should be installed
<glog78> i am also not really happy about jetpack cause JetpackSync seems not to deinstall
<OscarL> I used wget + cp to the correct place.
<glog78> maybe dein or plug is a better choice
<glog78> at least if that should become some sort of guide i would probably switch to something else
<OscarL> I was just happy to be able to add the cua-mode.vim thing without even knowing what I was doing (as usual)
<OscarL> Finally! Got both the lout package, and the Pe support for it working as I wanted!
<glog78> OscarL do you use python ?
<glog78> i can try pyls
<OscarL> I used Python daly for 6 years at work (python 2.4-2.7)... then forgot almost 80% of it... :-D
Diver has quit [Quit: Leaving.]
<OscarL> I think I've tried one of the py lsp... but can't remember which one...
<OscarL> surely was when trying the CudaText editor.
<OscarL> don't know which one is the one that YouCompleteMe for vim includes, that seems to work well enough to.
<OscarL> but having somthing working on gvim will be nice too :-)
<OscarL> Glog78 you could use a gist over github for your vimrc, so we can keep track of it.
<OscarL> (and won't expire)
<glog78> it's termbin not github
<OscarL> doesn't termibin expires pastes?
<glog78> pip3.10 install 'python-language-server[all]' | vimrc ->
<glog78> yes OscarL but if i make it available for a long time i need to clean up more
<OscarL> k.
<glog78> << just amazing if languages offer good documentation inside of the language
<glog78> one last thing today checking out if git fugitive works
<braewoods> Glog78: I heard it got arrested. :P
<glog78> ;)
<glog78> yes works fine
TMM has quit [Quit: - Chat comfortably. Anywhere.]
TMM has joined #haiku
ClaudioM has joined #haiku
<glog78> << last config update ;) it includes now git fugitive and swap files will be created outside of the project directories
<OscarL> swap fils are temp files?
<glog78> kinda
<glog78> if vim breaks you can recover from swap files
<OscarL> I might might wanna move those to /var/shared_memory/vim_temp.
<glog78> so it's good to survive a reboot in case of a kernel panic
<OscarL> I'm YOLOing it baby!
<glog78> :)
<OscarL> well... enough keyboard/head smashing finally resulted on 3 small PRs today. I call that a win.
<OscarL> (unless I get roasted at the reviews :-P)
* augiedoggie wonders why concourse is paused
OscarL has quit [Ping timeout: 480 seconds]
<augiedoggie> mm, just the bootstrap builds are paused
<augiedoggie> the nightly builds are failing on concourse, so it's not just me :P
<nekobot> [haiku/haiku] jscipione pushed 1 commit to master [hrev56948] -
<nekobot> [haiku/haiku] fc12af740f93 - netfs: Restore status_t result, fix build
<Skipp_OSX> damn it build breakage
<Skipp_OSX> I mean darn it
<glog78> i am laughing
<glog78> gh ...
<glog78> | changes -> better documention / automatic download Jetpack on first start
xet7 has quit [Ping timeout: 480 seconds]