I can’t believe i’m the first one to talk about it here? 
There is just another code editor for Haiku:
16 Likes
I’ve never heard of ecode before. So thanks for sharing this info.
2 Likes
The UI is drawn with SDL, right?
I like VScode, built in debugging would be nice, and I am a newb so, it is what it is
ooo, could this be the sublime replacement I’ve been hoping for?
1 Like
Hi there!
I’m the author of ecode. I’m glad that ecode catched the attention of haiku users.
I love Haiku and even have it running on bare metal. I don’t remember how to build packages for Haiku and I don’t have enough time to create the recipe to make it available in HaikuDepot but may be some of you can help with that. Meanwhile is just uploaded a haiku build in a gz file, it should work by just running the “ecode” bash script.
ecode uses OpenGL so the performance on Haiku isn’t ideal, it’s usable and feature-wise it seems that everything is working fine (not perfect, there are a couple of bugs in SDL2 here and there).
I hope you like it.
14 Likes
Thanks for uploading! note, I had to run the following command to get your bash to work (ecode archive extracted to my Desktop):
export LIBRARY_PATH=$LIBRARY_PATH:/boot/home/Desktop/ecode/libs
but when I load a file to try it out it crashes. 
UPDATE: Hmm… I tried a few more times and it is not crashing any more… odd. Also, I noticed it uses ctrl-key modifier by default (ctrl-c for copy, ctrl-v for paste, ctrl-f for find) and the not the usual ALT-key (alt-v, alt-c, alt-f) in Haiku. I’ll have to try editing the key bindings, but overall, looks very nice! I’ll need to tinker with it a bit more. great job!
2 Likes
Excellent!
Thanks for your feedback. Regarding the crash, I can create a release with the debug symbols so we can track it down with more ease.
I think I forgot to change the default modifier key for Haiku, but it’s trivial to change it, you’ll have to: Click on the top right wheel → Edit → Key Bindings → at the top of the file you’ll find something like:
[modifier]
mod=ctrl
just change ctrl for alt.
I’ll fix the library path later.
2 Likes
Haiku has lib/ next to your app folder in the library path oer default, if it does not make a difference for linux you could rename the folder also
Edit: since that is the only thing your script seems to be doing It would make running the application directly work properly.
2 Likes
CudaText could also be considered an alternative for that. There were some slightly outdated Haiku builds for it around, but not yet on HaikuDepot, I think (CudaText releases too often to keep up 
).
Thanks for the tip! I didn’t know about that!
A ‘working’ recipe with a build for CudaText has been around for a while, haven’t been able to update to a more recent version for 32bit: cudatext, 32bit version · Begasus/haikuports@14c6655 · GitHub
A sligthly older version for 64bit can be found at: GitHub - roired/CudaText-Haiku at release-1.146.2
1 Like
It’s a bit slow to start, but once it started it’s definitely usable.
Sadly it now crashes every time I start it after I had set UI scaling to 1.20
GalliumContext: CreateDisplay: Using llvmpipe (LLVM 12.0.1, 256 bits) driver.
ecode.bin: ../haiku-git/src/system/libroot/posix/malloc_hoard2/superblock.h:194:void BPrivate::superblock::putBlock(BPrivate::block*): getNumAvailable() < getNumBlocks()
./ecode: line 6: 27713 Kill Thread LD_LIBRARY_PATH=./libs ./ecode.bin "$@"
Yes, it’s really slow to start, I don’t really know why there’s such a difference compared to other OSes, for example, in Linux starts in about 150ms, same config here takes at least 3 seconds. I’ll try to investigate it. But I also notice this in general with Haiku (for example, building the project takes much longer, and I’m running on bare metal). AFAIK Haiku is not built with optimizations at the moment, that could explain the situation.
Can you please share me the contents of your ecode config, it’s located at: /boot/home/config/settings/ecode
I wasn’t able to reproduce the crash by changing the scale.
I uploaded a new version a couple of days ago, and also I just uploaded a new release that comes with debug symbols, we might be able to track the crash with a little more information. Here’s the downlad: https://github.com/SpartanJ/ecode/releases/download/ecode-0.4.1/ecode-haiku-0.4.1-x86_64-with-debug-symbols.tar.gz
Anyway, sadly the architecture of ecode isn’t ideal for Haiku, since it uses OpenGL for all its rendering and to be really performant we would need GPU hardware acceleration. I hope we get there soon.
That’s not quite right, we of course build with compiler optimizations enabled, we’re not that stupid.
What you may be thinking of:
- In nightly builds, the kernel has a lot more checks to make sure everything is OK and to avoid silent corruptions. It’s easier to debug when things crash as early as possible. But in release builds, this is not the case.
- We have not worked a lot on making Haiku fast, yet. We try to make it work first.
1 Like
Good day,
Well, CudaText has some peculiarities that make it a bit laborious to package a release:
1- The release model is quite fast… I never was able to keep up to match the release number.
2- Depends on several packages that need to be updated before building the software, so without the updated versions, it doesn’t build. And they are not packaged with CudaText, but scattered. Though all provided by the CudaText developer @Alexey-T.
3- CudaText is built (at least in my case) with Lazarus. I had issues adding the required packages to the CudaText Lazarus project in order to successfuly build CudaText, which results in long time testing and checking to achieve said successful build.
To be honest, though, Alexey is always willing to help, so that is a valuable matter to take into account.
As @Begasus pointed out, the 64 bit release is old. I tried to produce a newer release without success (back when I had time to do the test/check/build process). Will try with a new one as soon as I have time (another task to add to the task list … which is growing dangerously at the moment… 
).
Regarding launch time, I always get aroung 100 ms, though this depends on the modules loaded. The more the modules loaded at launch, the longer the time taken.
Anyway… task list is a FIFO, and I have a prior task I have to report to @lelldorin.
Regards,
RR
2 Likes
Thanks for the clarification. I vaguely remembered reading something like that. Is there any profiling tool available in Haiku that might help to track performance issues?
Compile times on Haiku seem to be about 30-50% more than Linux, at most; not double or worse than that. 150ms vs. 3 seconds also seems to be a lot. Perhaps there is some other problem on your machine in particular; you can try booting with ACPI disabled and see if this makes any noticeable difference, it has in other cases.
Yes, there’s profile (and a mode in which it outputs callgrind files, so you can use KCachegrind to analyze performance), and also strace.
This new release doesn’t crash anymore, great progress 
It’s still very slow to start, I’d say that 3 seconds it’s optimistic.
From what I could see from strace, most of the time it’s starting seems to be spent on /boot/home/config/cache/mesa_shader_cache/index, at least, while the window is blank it seems to be reading and seeking from there a lot.
1 Like
Thanks!
I was able to profile a little bit. It seems that most of the startup time is page faulting (function vm_page_fault). I know the app does a lot of allocations at startup, but I don’t think I can do much about it. Maybe someone here has a suggestion on how to improve it.