Re: [wip] howleditor 0.5.2

[James Turner]

On Sun, Nov 12, 2017 at 09:44:54AM +0100, Peter Ljung wrote:
> On Sat, Nov 4, 2017 at 4:15 PM, Peter Ljung  wrote:
> > On Fri, Oct 27, 2017 at 10:43 PM, James Turner  
> > wrote:
> >> On Fri, Oct 27, 2017 at 10:34:36PM +0200, Peter Ljung wrote:
> >>> On Thu, Oct 26, 2017 at 3:18 PM, James Turner  
> >>> wrote:
> >>> > On Wed, Oct 25, 2017 at 10:58:51PM +0200, Peter Ljung wrote:
> >>> >> This is my first attempt to make a port for the howl editor 
> >>> >> (https://howl.io/).
> >>> >>
> >>> >> I think howl is a *really* good alternative editor which compares well 
> >>> >> with e.g.
> >>> >> Sublime Text for my uses.
> >>> >>
> >>> >> Also it doesn't come with a huge baggage like the Electron based 
> >>> >> editors
> >>> >> Atom and VS Code.
> >>> >>
> >>> >> * The upstream code builds cleanly on OpenBSD since 0.4 release
> >>> >> * A stability issue (I found) on OpenBSD was fixed in last point 
> >>> >> release 0.5.2
> >>> >>
> >>> >> I have tried my best to create a suitable port.
> >>> >>
> >>> >> The current port is available at:
> >>> >>
> >>> >> https://github.com/peterljung/howleditor
> >>> >>
> >>> >> Some things I have came across ...
> >>> >>
> >>> >> * I have installed and tested the port on 6.1 and 6.2 release (amd64)
> >>> >> * It is called howleditor to avoid conflict with avahi
> >>> >> * Avahi has a "@conflict howl-*" in PLIST
> >>> >> * I made a small patch in the Makefile to force setting PREFIX variable
> >>> >>   which otherwise is set by ports infrastructure
> >>> >>
> >>> >> Any tips for improvements?
> >>> >>
> >>> >
> >>> > Hi Peter,
> >>> >
> >>> > Port looks pretty good. Biggest thing you're going to want to fix is how
> >>> > Howl downloads external dependencies and builds them locally. You will
> >>> > want to use our ports versions. Ie. LuaJIT, LPEG and maybe others.
> >>> >
> >>> > --
> >>> > James Turner
> >>>
> >>> Thanks for feedback!
> >>>
> >>> I actually asked upstream about using ports versions:
> >>>
> >>> As @kirbyfan64 said, we embed LuaJIT ourselves and link in statically. It 
> >>> would
> >>> be theoretically possible to use 2.0.5, but we switched to 2.1-beta two 
> >>> years
> >>> ago so I can't say for sure. Also, any LuaJIT would need to be compiled 
> >>> with the
> >>> correct compile options also (lua 5.2 compat enabled). We also patch 
> >>> LUA_IDSIZE
> >>> to be slightly larger.
> >>>
> >>> In short I see the desire to use a system Lua version, but as we don't 
> >>> link it
> >>> dynamically there's nothing to gain with regards to executable size, and 
> >>> the
> >>> needed changes above makes it not worth the while IMO. Release tarballs 
> >>> already
> >>> contain a bundled copy of LuaJIT.
> >>>
> >>> ...
> >>>
> >>> So there are some reasons not to use port versions, but someone with more
> >>> lua/porting experience might be able to determine what to do?
> >>>
> >>
> >> Makes sense, I guess I was more concerned with the port downloading
> >> dependencies, but if they are bundled with the tarball that takes care
> >> of that concern.
> >>
> >> What are other peoples thoughts?
> >>
> >> --
> >> James Turner
> >
> > I have made a few changes to the port from some suggestions by Edd.
> >
> > * I set PREFIX in MAKE_FLAGS as an alternative to patching the Makefile
> > * Added c++abi to WANTLIB
> > * Patched lpeg makefile to use clang (used gcc before)
> >
> > https://github.com/peterljung/howleditor/commits/master
> >
> > I also found an issue with the upstream release that need to be fixed.
> >
> > https://github.com/howl-editor/howl/issues/390
> 
> I have made a release bump to latest howl point release which includes a fix
> for the scrollbar issue.
> 
> https://github.com/peterljung/howleditor
> 
> It seems to work fine now, but more eyes and testing would obviously be great.
> 

Happy to provide an ok or import with another ok.

-- 
James Turner

Re: [wip] howleditor 0.5.2

[Peter Ljung]

On Sat, Nov 4, 2017 at 4:15 PM, Peter Ljung  wrote:
> On Fri, Oct 27, 2017 at 10:43 PM, James Turner  wrote:
>> On Fri, Oct 27, 2017 at 10:34:36PM +0200, Peter Ljung wrote:
>>> On Thu, Oct 26, 2017 at 3:18 PM, James Turner  wrote:
>>> > On Wed, Oct 25, 2017 at 10:58:51PM +0200, Peter Ljung wrote:
>>> >> This is my first attempt to make a port for the howl editor 
>>> >> (https://howl.io/).
>>> >>
>>> >> I think howl is a *really* good alternative editor which compares well 
>>> >> with e.g.
>>> >> Sublime Text for my uses.
>>> >>
>>> >> Also it doesn't come with a huge baggage like the Electron based editors
>>> >> Atom and VS Code.
>>> >>
>>> >> * The upstream code builds cleanly on OpenBSD since 0.4 release
>>> >> * A stability issue (I found) on OpenBSD was fixed in last point release 
>>> >> 0.5.2
>>> >>
>>> >> I have tried my best to create a suitable port.
>>> >>
>>> >> The current port is available at:
>>> >>
>>> >> https://github.com/peterljung/howleditor
>>> >>
>>> >> Some things I have came across ...
>>> >>
>>> >> * I have installed and tested the port on 6.1 and 6.2 release (amd64)
>>> >> * It is called howleditor to avoid conflict with avahi
>>> >> * Avahi has a "@conflict howl-*" in PLIST
>>> >> * I made a small patch in the Makefile to force setting PREFIX variable
>>> >>   which otherwise is set by ports infrastructure
>>> >>
>>> >> Any tips for improvements?
>>> >>
>>> >
>>> > Hi Peter,
>>> >
>>> > Port looks pretty good. Biggest thing you're going to want to fix is how
>>> > Howl downloads external dependencies and builds them locally. You will
>>> > want to use our ports versions. Ie. LuaJIT, LPEG and maybe others.
>>> >
>>> > --
>>> > James Turner
>>>
>>> Thanks for feedback!
>>>
>>> I actually asked upstream about using ports versions:
>>>
>>> As @kirbyfan64 said, we embed LuaJIT ourselves and link in statically. It 
>>> would
>>> be theoretically possible to use 2.0.5, but we switched to 2.1-beta two 
>>> years
>>> ago so I can't say for sure. Also, any LuaJIT would need to be compiled 
>>> with the
>>> correct compile options also (lua 5.2 compat enabled). We also patch 
>>> LUA_IDSIZE
>>> to be slightly larger.
>>>
>>> In short I see the desire to use a system Lua version, but as we don't link 
>>> it
>>> dynamically there's nothing to gain with regards to executable size, and the
>>> needed changes above makes it not worth the while IMO. Release tarballs 
>>> already
>>> contain a bundled copy of LuaJIT.
>>>
>>> ...
>>>
>>> So there are some reasons not to use port versions, but someone with more
>>> lua/porting experience might be able to determine what to do?
>>>
>>
>> Makes sense, I guess I was more concerned with the port downloading
>> dependencies, but if they are bundled with the tarball that takes care
>> of that concern.
>>
>> What are other peoples thoughts?
>>
>> --
>> James Turner
>
> I have made a few changes to the port from some suggestions by Edd.
>
> * I set PREFIX in MAKE_FLAGS as an alternative to patching the Makefile
> * Added c++abi to WANTLIB
> * Patched lpeg makefile to use clang (used gcc before)
>
> https://github.com/peterljung/howleditor/commits/master
>
> I also found an issue with the upstream release that need to be fixed.
>
> https://github.com/howl-editor/howl/issues/390

I have made a release bump to latest howl point release which includes a fix
for the scrollbar issue.

https://github.com/peterljung/howleditor

It seems to work fine now, but more eyes and testing would obviously be great.

Re: [wip] howleditor 0.5.2

[Peter Ljung]

On Fri, Oct 27, 2017 at 10:43 PM, James Turner  wrote:
> On Fri, Oct 27, 2017 at 10:34:36PM +0200, Peter Ljung wrote:
>> On Thu, Oct 26, 2017 at 3:18 PM, James Turner  wrote:
>> > On Wed, Oct 25, 2017 at 10:58:51PM +0200, Peter Ljung wrote:
>> >> This is my first attempt to make a port for the howl editor 
>> >> (https://howl.io/).
>> >>
>> >> I think howl is a *really* good alternative editor which compares well 
>> >> with e.g.
>> >> Sublime Text for my uses.
>> >>
>> >> Also it doesn't come with a huge baggage like the Electron based editors
>> >> Atom and VS Code.
>> >>
>> >> * The upstream code builds cleanly on OpenBSD since 0.4 release
>> >> * A stability issue (I found) on OpenBSD was fixed in last point release 
>> >> 0.5.2
>> >>
>> >> I have tried my best to create a suitable port.
>> >>
>> >> The current port is available at:
>> >>
>> >> https://github.com/peterljung/howleditor
>> >>
>> >> Some things I have came across ...
>> >>
>> >> * I have installed and tested the port on 6.1 and 6.2 release (amd64)
>> >> * It is called howleditor to avoid conflict with avahi
>> >> * Avahi has a "@conflict howl-*" in PLIST
>> >> * I made a small patch in the Makefile to force setting PREFIX variable
>> >>   which otherwise is set by ports infrastructure
>> >>
>> >> Any tips for improvements?
>> >>
>> >
>> > Hi Peter,
>> >
>> > Port looks pretty good. Biggest thing you're going to want to fix is how
>> > Howl downloads external dependencies and builds them locally. You will
>> > want to use our ports versions. Ie. LuaJIT, LPEG and maybe others.
>> >
>> > --
>> > James Turner
>>
>> Thanks for feedback!
>>
>> I actually asked upstream about using ports versions:
>>
>> As @kirbyfan64 said, we embed LuaJIT ourselves and link in statically. It 
>> would
>> be theoretically possible to use 2.0.5, but we switched to 2.1-beta two years
>> ago so I can't say for sure. Also, any LuaJIT would need to be compiled with 
>> the
>> correct compile options also (lua 5.2 compat enabled). We also patch 
>> LUA_IDSIZE
>> to be slightly larger.
>>
>> In short I see the desire to use a system Lua version, but as we don't link 
>> it
>> dynamically there's nothing to gain with regards to executable size, and the
>> needed changes above makes it not worth the while IMO. Release tarballs 
>> already
>> contain a bundled copy of LuaJIT.
>>
>> ...
>>
>> So there are some reasons not to use port versions, but someone with more
>> lua/porting experience might be able to determine what to do?
>>
>
> Makes sense, I guess I was more concerned with the port downloading
> dependencies, but if they are bundled with the tarball that takes care
> of that concern.
>
> What are other peoples thoughts?
>
> --
> James Turner

I have made a few changes to the port from some suggestions by Edd.

* I set PREFIX in MAKE_FLAGS as an alternative to patching the Makefile
* Added c++abi to WANTLIB
* Patched lpeg makefile to use clang (used gcc before)

https://github.com/peterljung/howleditor/commits/master

I also found an issue with the upstream release that need to be fixed.

https://github.com/howl-editor/howl/issues/390

Re: [wip] howleditor 0.5.2

[James Turner]

On Fri, Oct 27, 2017 at 10:34:36PM +0200, Peter Ljung wrote:
> On Thu, Oct 26, 2017 at 3:18 PM, James Turner  wrote:
> > On Wed, Oct 25, 2017 at 10:58:51PM +0200, Peter Ljung wrote:
> >> This is my first attempt to make a port for the howl editor 
> >> (https://howl.io/).
> >>
> >> I think howl is a *really* good alternative editor which compares well 
> >> with e.g.
> >> Sublime Text for my uses.
> >>
> >> Also it doesn't come with a huge baggage like the Electron based editors
> >> Atom and VS Code.
> >>
> >> * The upstream code builds cleanly on OpenBSD since 0.4 release
> >> * A stability issue (I found) on OpenBSD was fixed in last point release 
> >> 0.5.2
> >>
> >> I have tried my best to create a suitable port.
> >>
> >> The current port is available at:
> >>
> >> https://github.com/peterljung/howleditor
> >>
> >> Some things I have came across ...
> >>
> >> * I have installed and tested the port on 6.1 and 6.2 release (amd64)
> >> * It is called howleditor to avoid conflict with avahi
> >> * Avahi has a "@conflict howl-*" in PLIST
> >> * I made a small patch in the Makefile to force setting PREFIX variable
> >>   which otherwise is set by ports infrastructure
> >>
> >> Any tips for improvements?
> >>
> >
> > Hi Peter,
> >
> > Port looks pretty good. Biggest thing you're going to want to fix is how
> > Howl downloads external dependencies and builds them locally. You will
> > want to use our ports versions. Ie. LuaJIT, LPEG and maybe others.
> >
> > --
> > James Turner
> 
> Thanks for feedback!
> 
> I actually asked upstream about using ports versions:
> 
> As @kirbyfan64 said, we embed LuaJIT ourselves and link in statically. It 
> would
> be theoretically possible to use 2.0.5, but we switched to 2.1-beta two years
> ago so I can't say for sure. Also, any LuaJIT would need to be compiled with 
> the
> correct compile options also (lua 5.2 compat enabled). We also patch 
> LUA_IDSIZE
> to be slightly larger.
> 
> In short I see the desire to use a system Lua version, but as we don't link it
> dynamically there's nothing to gain with regards to executable size, and the
> needed changes above makes it not worth the while IMO. Release tarballs 
> already
> contain a bundled copy of LuaJIT.
> 
> ...
> 
> So there are some reasons not to use port versions, but someone with more
> lua/porting experience might be able to determine what to do?
> 

Makes sense, I guess I was more concerned with the port downloading
dependencies, but if they are bundled with the tarball that takes care
of that concern.

What are other peoples thoughts?

-- 
James Turner

Re: [wip] howleditor 0.5.2

[Peter Ljung]

On Thu, Oct 26, 2017 at 3:18 PM, James Turner  wrote:
> On Wed, Oct 25, 2017 at 10:58:51PM +0200, Peter Ljung wrote:
>> This is my first attempt to make a port for the howl editor 
>> (https://howl.io/).
>>
>> I think howl is a *really* good alternative editor which compares well with 
>> e.g.
>> Sublime Text for my uses.
>>
>> Also it doesn't come with a huge baggage like the Electron based editors
>> Atom and VS Code.
>>
>> * The upstream code builds cleanly on OpenBSD since 0.4 release
>> * A stability issue (I found) on OpenBSD was fixed in last point release 
>> 0.5.2
>>
>> I have tried my best to create a suitable port.
>>
>> The current port is available at:
>>
>> https://github.com/peterljung/howleditor
>>
>> Some things I have came across ...
>>
>> * I have installed and tested the port on 6.1 and 6.2 release (amd64)
>> * It is called howleditor to avoid conflict with avahi
>> * Avahi has a "@conflict howl-*" in PLIST
>> * I made a small patch in the Makefile to force setting PREFIX variable
>>   which otherwise is set by ports infrastructure
>>
>> Any tips for improvements?
>>
>
> Hi Peter,
>
> Port looks pretty good. Biggest thing you're going to want to fix is how
> Howl downloads external dependencies and builds them locally. You will
> want to use our ports versions. Ie. LuaJIT, LPEG and maybe others.
>
> --
> James Turner

Thanks for feedback!

I actually asked upstream about using ports versions:

As @kirbyfan64 said, we embed LuaJIT ourselves and link in statically. It would
be theoretically possible to use 2.0.5, but we switched to 2.1-beta two years
ago so I can't say for sure. Also, any LuaJIT would need to be compiled with the
correct compile options also (lua 5.2 compat enabled). We also patch LUA_IDSIZE
to be slightly larger.

In short I see the desire to use a system Lua version, but as we don't link it
dynamically there's nothing to gain with regards to executable size, and the
needed changes above makes it not worth the while IMO. Release tarballs already
contain a bundled copy of LuaJIT.

...

So there are some reasons not to use port versions, but someone with more
lua/porting experience might be able to determine what to do?

Re: [wip] howleditor 0.5.2

[James Turner]

On Wed, Oct 25, 2017 at 10:58:51PM +0200, Peter Ljung wrote:
> This is my first attempt to make a port for the howl editor 
> (https://howl.io/).
> 
> I think howl is a *really* good alternative editor which compares well with 
> e.g.
> Sublime Text for my uses.
> 
> Also it doesn't come with a huge baggage like the Electron based editors
> Atom and VS Code.
> 
> * The upstream code builds cleanly on OpenBSD since 0.4 release
> * A stability issue (I found) on OpenBSD was fixed in last point release 0.5.2
> 
> I have tried my best to create a suitable port.
> 
> The current port is available at:
> 
> https://github.com/peterljung/howleditor
> 
> Some things I have came across ...
> 
> * I have installed and tested the port on 6.1 and 6.2 release (amd64)
> * It is called howleditor to avoid conflict with avahi
> * Avahi has a "@conflict howl-*" in PLIST
> * I made a small patch in the Makefile to force setting PREFIX variable
>   which otherwise is set by ports infrastructure
> 
> Any tips for improvements?
> 

Hi Peter,

Port looks pretty good. Biggest thing you're going to want to fix is how
Howl downloads external dependencies and builds them locally. You will
want to use our ports versions. Ie. LuaJIT, LPEG and maybe others.

-- 
James Turner

[wip] howleditor 0.5.2

[Peter Ljung]

This is my first attempt to make a port for the howl editor (https://howl.io/).

I think howl is a *really* good alternative editor which compares well with e.g.
Sublime Text for my uses.

Also it doesn't come with a huge baggage like the Electron based editors
Atom and VS Code.

* The upstream code builds cleanly on OpenBSD since 0.4 release
* A stability issue (I found) on OpenBSD was fixed in last point release 0.5.2

I have tried my best to create a suitable port.

The current port is available at:

https://github.com/peterljung/howleditor

Some things I have came across ...

* I have installed and tested the port on 6.1 and 6.2 release (amd64)
* It is called howleditor to avoid conflict with avahi
* Avahi has a "@conflict howl-*" in PLIST
* I made a small patch in the Makefile to force setting PREFIX variable
  which otherwise is set by ports infrastructure

Any tips for improvements?