profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/infogulch/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Joe Taber infogulch Kansas City, MO

infogulch/AutoHotkey-StdLib 7

Standard library for all versions of the AutoHotkey Scripting language

infogulch/AsyncHttp 5

Easily make many asyncronous http requests. For AutoHotkey_L

infogulch/ahk-OpenGL 3

An OpenGL wrapper library/class for AutoHotkey_L that provides easy access to functions and constants

infogulch/ahk2-bigint 3

Arbitrary precision integer class for AutoHotkey v2 (currently alpha)

infogulch/CGUI 2

An object-oriented GUI library for AutoHotkey

infogulch/AutoHotkey_L 1

Custom build of AutoHotkey maintained by Lexikos.

infogulch/CaseSensitiveObject 1

Object proxy for AutoHotkey that provides case sensitive keys

infogulch/CGUI_Examples 1

Examples for the CGUI library

infogulch/fontutil 1

fontutil is a small collection of utility functions to make working with fonts easier in Go

infogulch/GenDocs 1

AutoHotkey documentation generator

issue commentjoaompinto/vscode-graphviz

Crash while previewing moderately large file

I'm also encountering the same issue and message with this extension (and other online dot rendererers).

It seems this extension is using the @hpcc-js/wasm library published to npm. That library is in active development and is now on 1.11.0, and this extension seems to be using 1.0.0.

I don't know if updating to the latest version would fix it or not, it seems like ALLOW_MEMORY_GROWTH=1 is set in the most recent version.

alexchandel

comment created time in 19 hours

startedbjorn3/rustc_codegen_cranelift

started time in 7 days

issue commentArchiveBox/ArchiveBox

Feature Request: Link directly to page position or highlighed selection

Is it feasible for a web page to control the browser's Find on page feature? I do not know if that is possible; I've never seen it before, as a specific instance or in the js api.

infogulch

comment created time in 11 days

issue commentArchiveBox/ArchiveBox

Feature Request: Link directly to page position or highlighed selection

For future reference, I've copied some of the js of the archive.is implementation of this feature below. Based on a quick skim, scrollToHash() seems to work by interpreting the location hash (e.g. #selection-1493.0-1493.53) as two document locations (e.g. 1493.0 and 1493.53) where the first part of each location (1493) is some bit-swizzled encoding of a path taken during a walk of all nodes in the document, and the second part (53) is the offset in the identified text node where that location begins/ends. Two of them give you a start and end point to remake the selection. Pretty neat idea, though the way pos is updated globally in a recursive descent through the document feels suspect to me.

There's no way this would be stable if the page were ever changed, but luckily these are archived pages we're talking about here. That said I can really see what you mean by "finnicky" 🤣.

I guess another consideration would be how this kind of "selection url" would work across different archive formats. The holy grail would be for such a selection link to translate across formats (e.g. warc/pdf/plain text) and degrade gracefully in the absence of the original format, but maybe that's setting the bar a bit high (like, geostationary orbit high 😅).

<details>

function updateShareLinks() {
  var shortlink = "http://archive.is/FWVL";
  var re = new RegExp(shortlink.replace(".", "\.") + "(#selection-[0-9.-]+)?");
  var adr = document.location.hash.match(/(selection-\d+\.\d+-\d+\.\d+)/);
  document.getElementById("SHARE_SHORTLINK").value = document.getElementById("SHARE_SHORTLINK").value.replace(re, adr ? shortlink + document.location.hash : shortlink);
  document.getElementById("SHARE_MARKDOWN" ).value = document.getElementById("SHARE_MARKDOWN" ).value.replace(re, adr ? shortlink + document.location.hash : shortlink);
  document.getElementById("SHARE_HTMLCODE" ).value = document.getElementById("SHARE_HTMLCODE" ).value.replace(re, adr ? shortlink + document.location.hash : shortlink);
  document.getElementById("SHARE_WIKICODE" ).value = document.getElementById("SHARE_WIKICODE" ).value.replace(re, adr ? shortlink + document.location.hash : shortlink);
}
function findXY(obj) {
  var cur = {x:0, y:0};
  while (obj && obj.offsetParent) {
    cur.x += obj.offsetLeft; // todo: + webkit-transform
    cur.y += obj.offsetTop; // todo: + webkit-transform
    obj = obj.offsetParent;
  }
  return cur;
}
function findXY2(obj, textpos) { // it could reset selection
  if (obj.nodeType==3) {
    var parent = obj.parentNode;
    var text = document.createTextNode(obj.data.substr(0, textpos));
    var artificial = document.createElement("SPAN");
    artificial.appendChild(document.createTextNode(obj.data.substr(textpos)));
    parent.insertBefore(text, obj);
    parent.replaceChild(artificial, obj);
    var y = findXY(artificial);
    parent.removeChild(text);
    parent.replaceChild(obj, artificial);
    return y;
  } else {
    return findXY(obj);
  }
}
var prevhash = "";
function scrollToHash() {
  if (document.location.hash.replace(/^#/, "")==prevhash.replace(/^#/, ""))
    return;
  prevhash = document.location.hash;
  if (document.location.hash.match(/#[0-9.]+%/)) {
    var p = parseFloat(document.location.hash.substring(1));
    if (0 < p && p < 100 /*&& p%5 != 0*/) {
      var content = document.getElementById("CONTENT")
      var y = findXY(content).y + (content.offsetHeight)*p/100;
      window.scrollTo(0, y-16);
    }
  }

  var adr = document.location.hash.match(/selection-(\d+)\.(\d+)-(\d+)\.(\d+)/);
  if (adr) {
    var pos=0,begin=null,end=null;
    function recur(e) {
      if (e.nodeType==1) pos = (pos&~1)+2;
      if (e.nodeType==3) pos = pos|1;
      if (pos==adr[1]) begin=[e, adr[2]];
      if (pos==adr[3]) end  =[e, adr[4]];
      for (var i=0; i<e.childNodes.length; i++)
        recur(e.childNodes[i]);
      if (e.childNodes.length>0 && e.lastChild.nodeType==3)
        pos = (pos&~1)+2;
    }
    var content = document.getElementById("CONTENT");
    recur(content.childNodes[content.childNodes[0].nodeType==3 ? 1 : 0]);
    if (begin!=null && end!=null) {
      window.scrollTo(0, findXY2(begin[0], begin[1]).y-8);

      if (window.getSelection) {
        var sel = window.getSelection();
        sel.removeAllRanges();
        var range = document.createRange();
        range.setStart(begin[0], begin[1]);
        range.setEnd  (  end[0],   end[1]);
        sel.addRange(range);
      } else if (document.selection) { // IE
      }
    }
  }
}
window.onhashchange = scrollToHash;
var initScrollToHashDone = false;
function initScrollToHash() {
  if (!initScrollToHashDone) {
    initScrollToHashDone = true;
    scrollToHash();
  }
}
window.onload = initScrollToHash;
setTimeout(initScrollToHash, 500); /* onload can be delayed by counter code */

</details>

infogulch

comment created time in 20 days

issue commentArchiveBox/ArchiveBox

Feature Request: Link directly to page position or highlighed selection

That's a reasonable judgement call, thanks for considering.

infogulch

comment created time in 20 days

issue commentArchiveBox/ArchiveBox

Feature Request: Link directly to page position or highlighed selection

I don't really like this solution for the following (somewhat related) reasons:

  • It depends on an experimental non-standard feature of Chrome which I don't use, and which Chrome may abandon in the future.
  • It would make huge, ugly links if you highlight a whole paragraph or more
  • Quoting a paragraph and then linking to the source (my main use-case) would feel dumb because the source text is copied twice
  • It's very unfriendly to plain-text representation of the link, like a chat window or simple blog comment
infogulch

comment created time in 21 days

issue commentArchiveBox/ArchiveBox

Feature Request: Link directly to page position or highlighed selection

@pirate is that a feature of the Link to Text Fragment chrome extension?

infogulch

comment created time in 22 days

issue openedArchiveBox/ArchiveBox

Feature Request: Link directly to page position or highlighed selection

Type

  • [x] Propose a brand new feature

What is the problem that your feature request solves

As a user, I would like to be able to share a particular location or selection on an archived page so that someone following the link will go directly to the relevant portion of the page without having to scroll or search manually.

Describe the ideal specific solution you'd want, and whether it fits into any broader scope of changes

Make a selection on the displayed page, which updates the url bar with a fragment. Copying that url and navigating to it in a different window would scroll to and highlight the selection again.

What hacks or alternative solutions have you tried to solve the problem?

The archive.is public archive supports this feature in two modes:

  • Link to percentage down the page: http://archive.is/FWVL#40%
  • Link to a specific selection in the page: http://archive.is/FWVL#selection-1493.0-1493.53

How badly do you want this new feature?

  • [x] It would be nice to have eventually

  • [x] I'm willing to contribute dev time / money to fix this issue
  • [x] I like ArchiveBox so far / would recommend it to a friend
  • [ ] I've had a lot of difficulty getting ArchiveBox set up

created time in 23 days

issue commentdhall-lang/dhall-lang

Add arithmetic operations for Natural and Integer

It's, in some sense, similar to the idea of having NonEmpty.fromList, which should "fail" for empty list inputs. They're both operations that are invalid for the "bottom value" (terminology?) of each type, so I would expect them to fail in the same way.

Your observation that both natural number zero and empty list are like the 'bottom value' is reasonable, though I would prefer 'zero value'. Also that for both Natural.div and NonEmpty.fromList the zero value is not present in the domain of each function respectively. But I think you're extrapolating too far when you imply that the reason why a value might be missing from a function's domain is because it's the zero value specifically. (Though I suspect you did not intend to imply this.) Consider the function λ(y: Natural) -> λ(x: Natural) -> Natural/div y (Natural/subtract 2 x), here the domain for x also omits the elements 1 and 2 because subtract saturates negatives to zero. Or a hypothetical Pairs.fromList that is only valid on a list with an even number of items.

My point is that the generalized way to consider functions that have some kind of 'invalid' input is to state that the invalid inputs are not part of the function's domain, and the fact that both of these functions have an invalid input that happens to be the zero value for that type, while true, is just incidental. In other words, the need to solve the problem of dealing with functions that have a domain smaller than their naive input type is broader than these cases.

Perhaps unsurprisingly, I think it's helpful to use the notion of a function's 'domain' (valid inputs) and 'range' (possible outputs) to describe this problem. The domain of div's divisor doesn't include zero, but the domain we would like to use, Natural, does include zero. There are two ways to reconcile these seemingly irreconcilable facts within our type system:

  1. We can invent a new type, say PositiveNatural, that omits zero and is therefore always valid to use as a divisor. Here the type of div would be Natural → PositiveNatural → Natural. Great. (Maybe this could also be implemented by div taking a proof that the divisor is nonzero ("validate_x" above) as an argument?) ... But it would be really convenient to not have to invent a new named type (and special constructor for instances) or other complex pre-validations just to represent the divisor which is this close to being the correct domain, which leads into option 2:
  2. Project any "extra" elements that aren't in the true domain of the function but are in the domain we wish to use out into to the range. Basically we extend the 'true' definition of div to include the zero element by also extending div's range with a special case so that the 'hole' is covered allowing us to use the more convenient domain (Natural) in exchange for having to deal with an extra element in the range. Here the type would be Natural → Natural → Option Natural as described by winitzki in the OP.

These two strategies have different consequences on the surrounding code. 1 means that the caller has to prove that the divisor is nonzero to construct a PositiveNatural but knows for sure that it will work if they get their hands on one. 2 means that the caller is less burdened up front because they only need to provide a regular Natural, but then they have to deal with the aftermath of the None case of the option if the divisor turned out to be zero. There are other pros and cons as well, but it's definitely more 'tradeoff' than 'right/wrong'. I don't know what the best answer for dhall is.

I hope this is more helpful than confusing. :)

winitzki

comment created time in 24 days

startedaleksilassila/litematica-printer

started time in a month

startedmaruohon/litematica

started time in a month

startedbevyengine/bevy

started time in a month

startedturbot/steampipe

started time in a month

starteduwu-tech/Kind

started time in a month

startedsycamore-rs/sycamore

started time in a month

startedockam-network/ockam

started time in a month

startedCaffeineMC/sodium-fabric

started time in a month

startedgnembon/fabric-carpet

started time in a month

issue commentshepmaster/sxd-document

Extremely large documents

Just in case you are unaware, there is another rust streaming xml parser named xml-rs.

infogulch

comment created time in a month

issue commentshepmaster/sxd-document

Extremely large documents

That did seem to help. Seemed to read at about 150MB/s this time.

 ➜ time QUIET=1 cargo run --release enwiki-20210720-pages-articles-multistream.xml
    Finished release [optimized + debuginfo] target(s) in 0.15s
     Running `target/release/sxd enwiki-20210720-pages-articles-multistream.xml`
Parsed 3313537136 tokens

real    9m5.861s
user    6m31.176s
sys     0m21.371s

Either way is fast enough for me, but what I'm looking for is a way to run xpath queries on it.

infogulch

comment created time in a month

startedosohq/oso

started time in a month

startedrslint/rslint

started time in a month

startedvmware/differential-datalog

started time in a month

startedmx00s/dhall-session-types

started time in a month

issue commentshepmaster/sxd-document

Extremely large documents

I'm a bit surprised that user + sys doesn't add up to real...

Good observation. Perhaps due to blocking on IO? I'll try with some different buffer sizes; 16 MB is pretty big but maybe the issue is waiting for the IO to go through, perhaps there's an opportunity to queue up the next buffer read while we're consuming the current one. Another complication is reading through the WSL syscall emulation, I'll also try running directly on windows. Unfortunately I don't have a linux set up on this system.

infogulch

comment created time in a month

startedopenzfsonwindows/ZFSin

started time in a month

issue commentshepmaster/sxd-document

Extremely large documents

parse the XML for the XSD and then generate some Rust code based on that

it's not really possible for Rust to express this in a generic manner right now (that requires generic associated types).

If you're generating rust the specific rust code for an xsd do you really need GAT? Or string interning for tags and attributes?

infogulch

comment created time in a month

issue commentshepmaster/sxd-document

Extremely large documents

Running under WSL with cargo 1.54.0 (5ae8d74b3 2021-06-22):

 ➜ time QUIET=1 cargo run --release /mnt/c/projects/static.wiki/enwiki-20210720-pages-articles-multistream.xml
    Finished release [optimized + debuginfo] target(s) in 0.02s
     Running `target/release/sxd /mnt/c/projects/static.wiki/enwiki-20210720-pages-articles-multistream.xml`
Parsed 3313537136 tokens

real    15m15.445s
user    6m54.255s
sys     0m11.748s
infogulch

comment created time in a month

startedshepmaster/sxd

started time in a month

startedtimbertson/dhall-render

started time in a month