Re: Next browser finally on master!
Hi, Sorry for taking so long to chime in. On Wed, 19 Dec 2018 22:32:22 +0100 Pierre Neidhardt wrote: > [...] > > That would not be consistent with the Lisp library naming scheme then. > And it raises the question as to why we have bothered with the sbcl- > and ecl- prefixes so far. > > Andy, any opinion on this? > That information is there to make sure that the transformer which converts sbcl packages to source and ecl packages works properly. If it's not being used, then there's no need to follow it. Even when it is being used, it's always possible to manually override the name of the final package - the convention is only there to make package name transformation automatic. So if it's more desirable in a given situation to use a non-conforming name, there's nothing that will prevent you from doing so. Hoping that helps, -- Andy
Re: Next browser finally on master!
Ricardo Wurmus writes: > The naming scheme applies to packages that are primarily used as > libraries. A package “foo” that is written in Python and also provides > modules that can be imported in an interactive Python session will not > be named “python-foo” when it is primarily used on its own. Agreed here. I don't want to speak out of turn and am interested in what Andy has to say here, but there are a few other Guix packages that do not follow their naming conventions when they are intended to be used alone. I think Idris is one. Perhaps it would confuse the end user if they were to know whether they were getting libraries for the SBCL environment to be able to hack on the package or if they were getting a runtime executable to operate the package without the SBCL environment. Brett Gilio
Re: Next browser finally on master!
Pierre Neidhardt writes: > Brett Gilio writes: >> Excuse me for not being fully aware, are you involved in the development >> of the Next browser? > > I am! John Mercouris is the original author, and I've implemented the > WebKitGTK > platform for Next. > Is there a mailing list for this, or is it Github-centric? I wouldn't mind throwing my hat in the ring if you all are looking for some extra development support. This might be off-topic so you can reply to me off of the list if you'd prefer. Brett Gilio
Re: Next browser finally on master!
Pierre Neidhardt writes: > - As far as I understand, the compiler *does* change the resulting > binary, thus the resulting REPL experience will be different, because > all Lisps are different beyond the ANSI standard and other undefined > behaviour. In other words, connecting via SLIME to ccl-next or > sbcl-next would result in a different environment. Sure. I wouldn’t expect people who use ECL to be able to load libraries that were built with SBCL. >> That these packages can *also* be used as libraries does not mean that the >> packages should have names with the “sbcl-” or “cl-” or “other-lisp-” prefix. > > That would not be consistent with the Lisp library naming scheme then. > And it raises the question as to why we have bothered with the sbcl- and > ecl- prefixes so far. The naming scheme applies to packages that are primarily used as libraries. A package “foo” that is written in Python and also provides modules that can be imported in an interactive Python session will not be named “python-foo” when it is primarily used on its own. -- Ricardo
Re: Next browser finally on master!
Brett Gilio writes: > Excuse me for not being fully aware, are you involved in the development > of the Next browser? I am! John Mercouris is the original author, and I've implemented the WebKitGTK platform for Next. Ricardo Wurmus writes: > I’ve read that discussion, but I don’t see how it is relevant. > The *name* of the package surely does not have any effect on the > features, does it? > > For applications like StumpWM and Next we could change the package names > to “stumpwm” and “next”, respectively. Don't get me wrong, I don't have a strong opinion against this change. But Lisp is special, and common sense for other packages / programming languages don't necessarily apply here. A few points to consider: - While StumpWM has dropped support for anything but SBCL, Next browser plans to support CCL (it already works but for one thing). So we could have a ccl-next package. - As far as I understand, the compiler *does* change the resulting binary, thus the resulting REPL experience will be different, because all Lisps are different beyond the ANSI standard and other undefined behaviour. In other words, connecting via SLIME to ccl-next or sbcl-next would result in a different environment. > That these packages can *also* be used as libraries does not mean that the > packages should have names with the “sbcl-” or “cl-” or “other-lisp-” prefix. That would not be consistent with the Lisp library naming scheme then. And it raises the question as to why we have bothered with the sbcl- and ecl- prefixes so far. Andy, any opinion on this? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Next browser finally on master!
Hi Pierre, >> I am also in favor >> of renaming SBCL-Next to something else. I know that we are using sbcl >> instead of clisp for building it, but the naming scheme seems to imply >> an SBCL library or module rather than a web browser application. > > This is being discussed for stumpwm in bug #33311. […] I’ve read that discussion, but I don’t see how it is relevant. The *name* of the package surely does not have any effect on the features, does it? For applications like StumpWM and Next we could change the package names to “stumpwm” and “next”, respectively. That these packages can *also* be used as libraries does not mean that the packages should have names with the “sbcl-” or “cl-” or “other-lisp-” prefix. Am I misunderstanding something? -- Ricardo
Re: Next browser finally on master!
Ricardo Wurmus writes: > Hi Pierre, > >>> I am also in favor >>> of renaming SBCL-Next to something else. I know that we are using sbcl >>> instead of clisp for building it, but the naming scheme seems to imply >>> an SBCL library or module rather than a web browser application. >> >> This is being discussed for stumpwm in bug #33311. […] > > I’ve read that discussion, but I don’t see how it is relevant. > The *name* of the package surely does not have any effect on the > features, does it? > > For applications like StumpWM and Next we could change the package names > to “stumpwm” and “next”, respectively. That these packages can *also* > be used as libraries does not mean that the packages should have names > with the “sbcl-” or “cl-” or “other-lisp-” prefix. > > Am I misunderstanding something? That was my understanding as well Ricardo. I do not see how renaming the package would detach it from its respective compiler. It should still be just as hackable in SLIME... Or so I thought? Brett
Re: Next browser finally on master!
Pierre Neidhardt writes: >> Hi all, I am also using the Next browser. A terrific tool. > > Oh, and I forgot: Thanks for the compliment! :) Excuse me for not being fully aware, are you involved in the development of the Next browser? I have been following it for some time, and am genuinely amazed by it. I have been a StumpWM + Emacs user for a long time, and combining Next with Guix my machine is pretty much LISP turtles all the way down (except the kernel). Brett
Re: Next browser finally on master!
Ludovic Courtès writes: > Hello! > > Pierre Neidhardt skribis: > >> I'm happy to let you know that after months of feisty packaging and the >> last month spent on the full rewrite of the GNU/Linux port, the Next web >> browser is finally on master! >> >> It's packaged as sbcl-next. > > Before reading your message I naively installed ‘next-webkit-gtk’, which > is not supposed to be used directly, right? Should we make it private > or hidden? > > Anyway, I’m trying it now and so far I like it! > > Thank you, > Ludo’. Hi all, I am also using the Next browser. A terrific tool. I am with you, Ludo, we should make next-webkit-gtk hidden and I am also in favor of renaming SBCL-Next to something else. I know that we are using sbcl instead of clisp for building it, but the naming scheme seems to imply an SBCL library or module rather than a web browser application. Brett Gilio
Re: Next browser finally on master!
> That’s because ‘guix size’ disables grafts, which allows it to check the > size of substitutes (build farms provide substitutes for ungrafted > variants.) > Before reading your message I naively installed ‘next-webkit-gtk’, which > is not supposed to be used directly, right? Should we make it private > or hidden? Hmm... I'm not sure. In the future, it could very well be that Next would have a "next-qt-webengine" platform, for instance. Then the user will have the possibility to choose explicitly. Another reason for keeping it public is that it's possible to install next-gtk-webkit on a system and have the Lisp core run on a remote machine(!!!). Well... > No. > > I assume you created the pack with: > > guix pack --relocatable -S /bin=bin sbcl-next > > Correct? > > And then you tried running it on a foreign distro? Yes and yes. > Is there a simple way to test it on a headless distro? So far, next-gtk-webkit needs a display. Its implementation was not really done with headless systems in mind. That said, it's testable on a virtual machine with a display, everything can be driven by Lisp. > Anyway, I’m trying it now and so far I like it! Thanks! It's still very alpha, but master already has much more: cookie support, echo area / status, copy/paste, etc. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Next browser finally on master!
Pierre Neidhardt skribis: > Forget the above, I was wrong. "guix pack" works well with regard to finding > the correct executable, with or without graft (could be wrong again, but so > far > it seems to work). > > The issue is that "next" cannot send XML-RPC requests to "next-gtk-webkit". > It > keeps polling it, but nothing flows through. > > "next-gtk-webkit" seems to be working well however, the port 8081 is correctly > open. > > I really wonder why the "next" executable fails to communicate with 8081. > > Question: Is there some network limitations when running a relocated "guix > pack"? No. I assume you created the pack with: guix pack --relocatable -S /bin=bin sbcl-next Correct? And then you tried running it on a foreign distro? Is there a simple way to test it on a headless distro? Thanks, Ludo’.
Re: Next browser finally on master!
Pierre Neidhardt skribis: > Hmm, I'm having an issue with Guix pack. > > Check out the following: > > $ ./pre-inst-env guix build next-gtk-webkit > /gnu/store/ildn4l2wr0y7irm2536dnp88hhrdphsz-next-gtk-webkit-1.1.0 > > $ ./pre-inst-env guix size next-gtk-webkit > store item totalself > /gnu/store/fd706jbvrk8zvk6175sz42xqbgc3krsg-webkitgtk-2.20.5 1057.9 > 130.3 12.1% That’s because ‘guix size’ disables grafts, which allows it to check the size of substitutes (build farms provide substitutes for ungrafted variants.) Ludo’.
Re: Next browser finally on master!
Hello! Pierre Neidhardt skribis: > I'm happy to let you know that after months of feisty packaging and the > last month spent on the full rewrite of the GNU/Linux port, the Next web > browser is finally on master! > > It's packaged as sbcl-next. Before reading your message I naively installed ‘next-webkit-gtk’, which is not supposed to be used directly, right? Should we make it private or hidden? Anyway, I’m trying it now and so far I like it! Thank you, Ludo’.
Re: Next browser finally on master!
On 2018-12-11 08:46, Pierre Neidhardt wrote:
> Hi! Thanks for the feedback.
>
>> M-x
>> scroll the list to the bottom (with down-arrow) (freezez at
>> JUMP-TO-HEADING)
>
> I can't reproduce this. Can you produce this systematically? Can you post
> the
> content of /tmp/next-gtk-webkit.log?
On startup it works. Clicking a link and trying makes it freeze :D
See log arrached
Cannot reproduce scroll page freeze right now. will return when I have
an example.
>
>> “next-gtk-webkit” is not responding."
>
> Where do you see that?
Gnome-message after it has been frozen some time. not relevant...
>
> Note that next-gtk-webkit is quite stable on its own, the issue is with
> WebKitGTK. I still need to tinker with it a little, and hopefully the
> situation
> will get much better.
In vimb the crash on query.wikidata.org is not freezing it up. it simply
displays an error in the bottom and continues to work.
>
>> navigate to some page on youtube
>> press play and seek (freezes when trying to seek)
>> (gstreamer, clutter-gst, gst good, base libav installed)
>
> Can you play any video?!? I can't play any video at all on GuixSD. I works
> on
> Arch Linux though.
yes, they play but VP/webm lag. mp4 does not though!
tested here:
https://goblinrefuge.com/mediagoblin/u/praveenvarma/m/enrre-vidyaalyN-1/
the mp4 plays perfect.
the vp/webm lags and it becomes non fluent to watch.
i'm on 64bity x86 but with i686 guix :)
>
> Currently, I've setup the following workaround in ~/.config/next/init.lisp to
> play videos with mpv.
>
> --8<---cut here---start->8---
> (define-command play-video-in-current-page ()
> "Play video in the currently open buffer."
> (with-result (url (buffer-get-url))
> (uiop:run-program (list "mpv" url
> (define-key *global-map* (key "C-M-c v") 'play-video-in-current-page)
> --8<---cut here---end--->8---
Will try it and report back :)
>
>> I tried it out for some time now. Unfortunately it is buggy and freezes
>> on me with no backtrace provided :-/.
>
> Stay tuned, next release (hopefully by next week) will be much, much better!
Nice!
--
Cheers
Swedebugia** Message: 09:01:08.800: Method name: window.make
** Message: 09:01:08.856: Method result(s): window id 0
** Message: 09:01:08.984: Method name: buffer.make
** Message: 09:01:08.986: Method result(s): buffer id 0
** Message: 09:01:09.256: Method name: buffer.evaluate.javascript
** Message: 09:01:09.256: Method parameter(s): buffer id 0
** Message: 09:01:09.256: Method result(s): callback id 0
** Message: 09:01:09.262: Method name: window.set.active.buffer
** Message: 09:01:09.262: Method parameter(s): window id 0, buffer id 0
** Message: 09:01:09.262: Window 0 switches from buffer (null) to 0
** Message: 09:01:09.317: XML-RPC message: BUFFER-JAVASCRIPT-CALL-BACK (buffer
id, javascript, callback id) = (0, ..., 0)
** Message: 09:01:09.486: Method name: buffer.evaluate.javascript
** Message: 09:01:09.486: Method parameter(s): buffer id 0
** Message: 09:01:09.486: Method result(s): callback id 1
** Message: 09:01:09.506: XML-RPC message: BUFFER-JAVASCRIPT-CALL-BACK (buffer
id, javascript, callback id) = (0, ..., 1)
** Message: 09:01:10.279: XML-RPC message: BUFFER-DID-COMMIT-NAVIGATION ('0',
'https://next.atlas.engineer/quickstart')
** Message: 09:01:14.692: XML-RPC message: PUSH-KEY-EVENT (keycode, keyval,
modifiers, window id) = (53, 'x', ['M'], '0')
** Message: 09:01:14.694: XML-RPC message: CONSUME-KEY-SEQUENCE, window id 0
** Message: 09:01:14.705: Method name: window.active
** Message: 09:01:14.705: Method parameter(s): 0
** Message: 09:01:14.706: Method name: window.active
** Message: 09:01:14.706: Method parameter(s): 0
** Message: 09:01:14.707: Method name: minibuffer.evaluate.javascript
** Message: 09:01:14.707: Method parameter(s): window id 0
** Message: 09:01:14.708: Method result(s): callback id 0
** (next-gtk-webkit:8821): WARNING **: 09:01:14.724: Error running javascript:
unexpected return value
** Message: 09:01:14.737: Method name: window.active
** Message: 09:01:14.737: Method parameter(s): 0
** Message: 09:01:14.739: Method name: minibuffer.evaluate.javascript
** Message: 09:01:14.739: Method parameter(s): window id 0
** Message: 09:01:14.739: Method result(s): callback id 1
** (next-gtk-webkit:8821): WARNING **: 09:01:14.740: Error running javascript:
unexpected return value
** Message: 09:01:14.756: Method name: window.active
** Message: 09:01:14.756: Method parameter(s): 0
** Message: 09:01:14.758: Method name: minibuffer.evaluate.javascript
** Message: 09:01:14.758: Method parameter(s): window id 0
** Message: 09:01:14.758: Method result(s): callback id 2
** Message: 09:01:14.759: Method name: window.active
** Message: 09:01:14.759: Method parameter(s): 0
** Message: 09:01:14.761: Method name: window.set.minibuffer.height
** Message: 09:01:14.761: Method parameter(s): window id 0, minibuffer height
200
**
Re: Next browser finally on master!
Hi! Thanks for the feedback. > M-x > scroll the list to the bottom (with down-arrow) (freezez at > JUMP-TO-HEADING) I can't reproduce this. Can you produce this systematically? Can you post the content of /tmp/next-gtk-webkit.log? > “next-gtk-webkit” is not responding." Where do you see that? Note that next-gtk-webkit is quite stable on its own, the issue is with WebKitGTK. I still need to tinker with it a little, and hopefully the situation will get much better. > navigate to some page on youtube > press play and seek (freezes when trying to seek) > (gstreamer, clutter-gst, gst good, base libav installed) Can you play any video?!? I can't play any video at all on GuixSD. I works on Arch Linux though. Currently, I've setup the following workaround in ~/.config/next/init.lisp to play videos with mpv. --8<---cut here---start->8--- (define-command play-video-in-current-page () "Play video in the currently open buffer." (with-result (url (buffer-get-url)) (uiop:run-program (list "mpv" url (define-key *global-map* (key "C-M-c v") 'play-video-in-current-page) --8<---cut here---end--->8--- > I tried it out for some time now. Unfortunately it is buggy and freezes > on me with no backtrace provided :-/. Stay tuned, next release (hopefully by next week) will be much, much better! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Next browser finally on master!
On 2018-12-05 11:34, Pierre Neidhardt wrote: snip > It's still rather alpha and some features are missing (such as cookie > support), but rest assured it won't take long! > > As always, feedback is more than welcome! I tried it out for some time now. Unfortunately it is buggy and freezes on me with no backtrace provided :-/. sdb@antelope ~$ guix --version guix (GNU Guix) 0.16.0-3.6ddc63e Reproduce: M-x scroll the list to the bottom (with down-arrow) (freezez at JUMP-TO-HEADING) “next-gtk-webkit” is not responding." Reproduce: navigate to some page on youtube press play and seek (freezes when trying to seek) (gstreamer, clutter-gst, gst good, base libav installed) -- Cheers Swedebugia
Re: Next browser finally on master!
Actually, here is a clue: > ./pre-inst-env guix build --check next-gtk-webkit The following graft will be made: /gnu/store/jgb5j3pg45kf19n7cgw1j5kjagzmbqg1-next-gtk-webkit-1.1.0.drv applying 2 grafts for /gnu/store/jgb5j3pg45kf19n7cgw1j5kjagzmbqg1-next-gtk-webkit-1.1.0.drv... grafting '/gnu/store/8llinghxcslyxmvszjlvlxbv411vra0x-next-gtk-webkit-1.1.0' -> '/gnu/store/ildn4l2wr0y7irm2536dnp88hhrdphsz-next-gtk-webkit-1.1.0'... /gnu/store/ildn4l2wr0y7irm2536dnp88hhrdphsz-next-gtk-webkit-1.1.0 So it's a grafting issue, probably caused by a dependency. - How can I know which dependency causes the graft? - Why isn't grafting taken into account by `guix size` and `guix pack`? - Is `guix pack --no-grafts` the way to go? Well, I'll try that... -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Next browser finally on master!
Hmm, I'm having an issue with Guix pack. Check out the following: --8<---cut here---start->8--- $ ./pre-inst-env guix build next-gtk-webkit /gnu/store/ildn4l2wr0y7irm2536dnp88hhrdphsz-next-gtk-webkit-1.1.0 $ ./pre-inst-env guix size next-gtk-webkit store item totalself /gnu/store/fd706jbvrk8zvk6175sz42xqbgc3krsg-webkitgtk-2.20.5 1057.9 130.3 12.1% ... /gnu/store/8llinghxcslyxmvszjlvlxbv411vra0x-next-gtk-webkit-1.1.0 1073.6 0.0 0.0% /gnu/store/gcp2zwbl5zbv0jvx7fnm8hc1lbzkvpkp-libxcomposite-0.4.4 79.5 0.0 0.0% /gnu/store/mcd9pz6miv4wsrwlzam18akn3nix0ysa-libxinerama-1.1.4 80.0 0.0 0.0% /gnu/store/6hq2ha8hfghnkrnrpawx2vlsp88zq537-libxdamage-1.1.479.6 0.0 0.0% /gnu/store/hcxcbbsf0p1fzjajd2idc3j5qvlyyp5w-libxshmfence-1.368.0 0.0 0.0% /gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0 188.4 0.0 0.0% total: 1073.6 MiB --8<---cut here---end--->8--- The two next-gtk-webkit have a different store path. Any idea why? What happens when I make the Guix pack is that sbcl-next is built against /gnu/store/8llinghxcslyxmvszjlvlxbv411vra0x-next-gtk-webkit-1.1.0 but /gnu/store/ildn4l2wr0y7irm2536dnp88hhrdphsz-next-gtk-webkit-1.1.0 is included in the archive. I generate the archive with $ ./pre-inst-env guix pack --relocatable --compression=lzip --symlink=/bin=bin sbcl-next Anyone? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Next browser finally on master!
On Thu, Dec 06, 2018 at 03:03:07PM +0100, Pierre Neidhardt wrote:
> > I cannot run ./bin/next, as it is looking for /gnu/store/...
> Do you have the full backtrace?
Unhandled SIMPLE-ERROR in thread #:
Couldn't execute
"/gnu/store/8llinghxcslyxmvszjlvlxbv411vra0x-next-gtk-webkit-1.1.0/bin/next-gtk-webkit":
No such file or directory
Backtrace for: #
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK # # :QUIT T)
1: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #)
2: (INVOKE-DEBUGGER #)
3: (UIOP/IMAGE:HANDLE-FATAL-CONDITION #)
4: (SB-KERNEL::%SIGNAL #)
5: (ERROR "Couldn't execute ~S: ~A"
"/gnu/store/8llinghxcslyxmvszjlvlxbv411vra0x-next-gtk-webkit-1.1.0/bin/next-gtk-webkit"
"No such file or directory")
6: (RUN-PROGRAM
"/gnu/store/8llinghxcslyxmvszjlvlxbv411vra0x-next-gtk-webkit-1.1.0/bin/next-gtk-webkit"
("--port" "8082" "--core-socket" "http://localhost:8081/RPC2;) :ENV NIL
:ENVIRONMENT NIL :WAIT NIL :SEARCH T :PTY NIL :INPUT NIL
:IF-INPUT-DOES-NOT-EXIST :ERROR :OUTPUT #P"/tmp/next-gtk-webkit.log"
:IF-OUTPUT-EXISTS :APPEND :ERROR :OUTPUT :IF-ERROR-EXISTS :APPEND :STATUS-HOOK
NIL :EXTERNAL-FORMAT :UTF-8 :DIRECTORY NIL)
7: (UIOP/LAUNCH-PROGRAM:LAUNCH-PROGRAM
("/gnu/store/8llinghxcslyxmvszjlvlxbv411vra0x-next-gtk-webkit-1.1.0/bin/next-gtk-webkit"
"--port" "8082" "--core-socket" "http://localhost:8081/RPC2;) :OUTPUT
#P"/tmp/next-gtk-webkit.log" :ERROR-OUTPUT :OUTPUT)
8: ((:METHOD NEXT::RUN-PROGRAM (NEXT::PORT)) #)
[fast-method]
9: (NEXT:START :WITH-PLATFORM-PORT-P T)
10: (NEXT-EXEC:MAIN)
11: ((LAMBDA NIL :IN UIOP/IMAGE:RESTORE-IMAGE))
12: (UIOP/IMAGE:CALL-WITH-FATAL-CONDITION-HANDLER #)
13: ((FLET SB-UNIX::BODY :IN SAVE-LISP-AND-DIE))
14: ((FLET "WITHOUT-INTERRUPTS-BODY-27" :IN SAVE-LISP-AND-DIE))
15: ((LABELS SB-IMPL::RESTART-LISP :IN SAVE-LISP-AND-DIE))
unhandled condition in --disable-debugger mode, quitting
> I know there is an issue at the moment, it's looking for the wrong
> /gnu/store/...-next-gtk-webkit. I'm not sure what's wrong, I'll look into it.
This must be it. I misunderstood the error as meaning that I had to remap
myself /gnu/store to ./gnu/store somehow before starting the program.
Andreas
Re: Next browser finally on master!
> I cannot run ./bin/next, as it is looking for /gnu/store/... Do you have the full backtrace? I know there is an issue at the moment, it's looking for the wrong /gnu/store/...-next-gtk-webkit. I'm not sure what's wrong, I'll look into it. > How do I change / to be .? Documentation is being reworked, but generally it is very similar to Emacs. If you want bind a new key: (define-key *global-map* (key ".") 'whatever-command-here) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Next browser finally on master!
On Thu, Dec 06, 2018 at 09:31:45AM +0100, Pierre Neidhardt wrote: > > It seems to be the first ever? software project distributed reproducibly > > with guix pack :) > Indeed, haha! :) Still having issues with it though, hopefully I'll fix it > later today. Otherwise I'll ask for more help here ;) Amazing indeed! But the documentation lacks one little explanation: How do I change / to be .? I turned on user name spaces as explained, but then I cannot run ./bin/next, as it is looking for /gnu/store/... Andreas
Re: Next browser finally on master!
> It seems to be the first ever? software project distributed reproducibly > with guix pack :) Indeed, haha! :) Still having issues with it though, hopefully I'll fix it later today. Otherwise I'll ask for more help here ;) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Next browser finally on master!
On 2018-12-05 11:34, Pierre Neidhardt wrote: > Hi Guix! > > I'm happy to let you know that after months of feisty packaging and the > last month spent on the full rewrite of the GNU/Linux port, the Next web > browser is finally on master! > > It's packaged as sbcl-next. > > Next is a web browser written in Common Lisp, designed after Emacs: one > of its alleged goals is to bring extreme extensibility to the world of > web browsers! (VI lovers, don't worry, VI-style bindings are coming!) > > See https://next.atlas.engineer for some cool examples. > > It's still rather alpha and some features are missing (such as cookie > support), but rest assured it won't take long! > > As always, feedback is more than welcome! > Happy hacking! Congratiolations! I look forward to trying it out as none of the browsers I use really satisfy my needs. It seems to be the first ever? software project distributed reproducibly with guix pack :) -- Cheers Swedebugia
Re: Next browser finally on master!
Hi Ben, Thanks for the praise! I've already made it my default browser, so it's that usable at least! More good stuff is coming, off the top of my head: - VI-style bindings - cookies - status bar - proxy settings (and more WebKit related options) - Extended minibuffer (think Helm or Ivy!) - A greatly improved bookmark system - Password manager integration - :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Next browser finally on master!
Pierre, This is great news! Just installed it via Guix and played with it for a minute or two and am looking forward to more extensive use. cheers, -Ben -- Benjamin Slade - https://babbagefiles.xyz `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19)) '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org ) `(Choose Linux ,(Choose Freedom) . https://linux.com )
Next browser finally on master!
Hi Guix! I'm happy to let you know that after months of feisty packaging and the last month spent on the full rewrite of the GNU/Linux port, the Next web browser is finally on master! It's packaged as sbcl-next. Next is a web browser written in Common Lisp, designed after Emacs: one of its alleged goals is to bring extreme extensibility to the world of web browsers! (VI lovers, don't worry, VI-style bindings are coming!) See https://next.atlas.engineer for some cool examples. It's still rather alpha and some features are missing (such as cookie support), but rest assured it won't take long! As always, feedback is more than welcome! Happy hacking! Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
