Hacker Newsnew | past | comments | ask | show | jobs | submit | more listeria's commentslogin

Shouldn't you have added a disclaimer, Mr. Founder of Plandex: an open source AI coding agent?


What should my disclaimer be? That I'm building something which is open source and consistent with my beliefs?


I was actually thinking about something like this:

"disclaimer: I'm the founder of Plandex: an open source AI coding agent"

Note that I wouldn't personally add "open source", I don't think it adds to the discussion, but it's what I would have expected to see.


Is it relevant? This is not a post about AI coding, and Plandex is not a startup that "went from X to AI-powered X". It also has very little to do with adding AI features to a product... it's a general purpose coding agent, not a tool for building AI features specifically.

I mean, I discuss AI a lot on HN. Do I need to include a disclaimer on every comment?


I think perhaps more important is wether or not you've accepted funding from venture capital, as this would substantially reduce the moral argument made by claiming you're making something open source (as OSS essentially the playbook for developing initial growth in VC land).


I've raised a small amount of funding yes. The project wouldn't exist otherwise. I have a family to feed.

But the open source project is free, full-featured, MIT licensed, and will stay that way.

It also has paying customers via cloud-hosting options, and the economics are working out well so far, fwiw. Lots of work to do, but it's on track to be both a sustainable open source project and a sustainable business.

I'm sorry if that still doesn't meet your lofty moral standards—all I can really say is I'm trying my best to get the balance right.


Fair enough, I am fairly cynical on this subject in particular so my biases got the best of me. Thanks for open sourcing your project (MIT in particular).


If the goal of testing on obscure compilers is to enhance such compilers then I'm all for it. But I don't see much value in having to dance around implementation details to support a compiler which isn't standards compliant. Ideally standards conforming code should just work, that's the point of conforming to a standard.


Depends if you want people to be able to use your library with those compilers or not. If it's free software, fine. Don't fire well-paying customers though.


Apparently the static_assert trick doesn't work with GCC, it just compiles it with a warning if it's not a constant expression:

  warning: expression in static assertion is not an integer constant expression [-Wpedantic]
Instead you can use the sizeof + compound literal with array type, use the comma operator to preserve the type of the expression and cast the result of sizeof to void to suppress the warning:

  #define C(x) ( (void)sizeof( (char [(int)(x) || 1]){0} ), (x) )
The only problem is that it doesn't support floating point expressions


incidentally, the block allocator implementation fails to properly account for alignment requirements:

since the underlying storage is std::array<char, ...>, it's alignment may be less that the required alignment of the requested type and that of the pointers being stored in the free list.


You absolutely can do that in C++ with consteval + template, what's more, you don't even need consteval, constexpr will suffice:

  #include <cstdio>
  
  namespace detail {
  template<size_t N>
  struct Capitalize {
    char data[N];
    constexpr Capitalize(const char (&tag)[N]) : data{} {
      for (size_t i = 0; i < N; i++)
        data[i] = tag[i];
      data[0] &= 95;
    }
  };
  }
  
  template<typename T, size_t N, const char (&tag)[N], size_t count>
  struct MyType {
    static constexpr auto capitalized = detail::Capitalize(tag);
    constexpr auto name() const {
      return capitalized.data;
    }
    T array[count];
  };
  
  int main() {
    static constexpr char hello[] = "hello";
    MyType<int, sizeof(hello), hello, 10> value{};
    std::puts(value.name());
  }
I'd agree that zig's comptime encompasses many of C++'s features, and I appreciate the approach they took to new features by way of builtins (like @typeInfo + @Type for reflection), but this is not a good example.

Furthermore, why is type traits among the list of features that you claim is subsumed by comptime? not only is that not the case, but type traits are not so much a feature of C++ as they are of its standard library, implemented using templates (a feature of the language).


I tried your example and got an error:

  error: type capture contains reference to comptime var
I'm not sure how you were suppossed to use it but here's my attempt:

  fn capitalize(tag: []u8) []u8 {
      tag[0] &= 95;
      return tag;
  }

  fn MyType(T: type, comptime tag: []u8, comptime count: usize) type {
      const capitalized = capitalize(tag);
      return struct {
          fn name() []const u8 {
              return capitalized;
          }
          array: [count]T,
      };
  }

  pub fn main() void {
      comptime var hello: [5]u8 = undefined;
      @memcpy(&hello, "hello");

      var v: MyType(i32, &hello, 10) = undefined;
      v.name();
  }
If you allow `capitalized` to be it's own instance then there's no reason to mutate the comptime parameter in the first place, and it can be replicated in C++17.


I'd normally agree with you, but in this case this function is meant to be used for vectorizable input so it doesn't really matter since it's using a random-access iterator, otherwise you should go with the usual std::count_if().

Then again, it doesn't hurt to be pedantic.


It's not about being pedantic, it's about building the right habits. Building a habit of using x++ instead of ++x is suboptimal.


I also wrote a small tool to generate more templates, and it fits in a comment:

  usage: weeks YYYY-MM-DD YYYY-MM-DD
  
  weeks () {
      one_day=$((60 * 60 * 24))
      unix_from=$(date +%s --date="$1")
      unix_to=$(date +%s --date="$2")
  
      while [ $unix_from -lt $unix_to ]
      do
          echo @$unix_from
          unix_from=$((unix_from + one_day))
      done | date +'%F w%V %a' -f -
  
      unset -v one_day unix_from unix_to
  }
seriously, what's a compressed 1.2MB small tool?


Nice!

Static binaries generated by Go are indeed large, even if the source code here is under 30 lines with support to some additional minor features (US and Finnish day names, command line help, optional week headings, day counts and parameter handling).

Here are some more scripts to generate calendar.txt date format:

https://terokarvinen.com/2024/format-date-calendar-txt/


on the topic of alignment, the library (libpool) fails to align chunk_sz to allow storing a pointer when in the free_chunk list.

This issue is sidestepped in TFA by using a union, which ensures appropiate alignment for all it's members, but in the library there's nothing which prevents me from asking for a chunk size of, say, 9 bytes, which would store pointers at misaligned addresses when creating the free-list.


    package main

    import "fmt"

    func main() {
        fmt.Println("Hello world")
    }



Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: