profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Scimonster/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.

photopea/UPNG.js 1499

Fast and advanced PNG (APNG) decoder and encoder (lossy / lossless)

photopea/UTIF.js 236

Fast and advanced TIFF decoder

Scimonster/js-gematriya 14

Convert numbers to gematriya representation, and vice-versa.

Scimonster/js-xlsx-plus 3

A wrapper for js-xlsx with getters

Scimonster/jquery-ui-alert 1

Provides fully customizable jQuery UI-styled alert, confirm, and prompt dialogs. Requires jQuery and jQuery UI, with at least the dialog module.

Scimonster/localBrowse 1

A file manager+editor to run in the browser with Node.js

Scimonster/components-jqueryui 0

Shim repository for jQuery UI.

Scimonster/darkreader 0

Dark Reader Chrome and Firefox extension

Scimonster/DjangoBB 0

This is a fork of a fork of DjangoBB customized for Scratch 2.0, and edited by me, to fix bugs and add features. Except that i don't really know Python. :P DjangoBB is a quick and simple forum which uses the Django Framework (written in Python language). Abbreviation DjangoBB stands for Django Bulletin Board. DjangoBB is distributed under the BSD license.

issue closedhebcal/hebcal

Sunrise/sunset changes by large amount between February and March

I am noticing a very large change in the time for sunrise (and sunset) between 02-28 and 03-01. This seems to be true in every calendar year, which leads me to believe there is a bug somewhere in the Hebcal code that is causing this. My hunch is that February only having 28 (or 29) days might have something to do with it.

For example, if we look at sunrise in 07666 for 2021-02-28 (https://www.hebcal.com/zmanim?cfg=json&start=2021-02-28&geo=zip&zip=07666) it is 06:36, but for 2021-03-01 (https://www.hebcal.com/zmanim?cfg=json&start=2021-03-01&geo=zip&zip=07666) it is 06:30. That's a difference of 6 minutes in just one day, whereas the differences between the previous day (2021-02-27) is 1 minute and subsequent day (2021-03-02) is only 2 minutes.

I brought this up to @nkasimer who created a spreadsheet of the change in sunrise times for 999 days in 07666 starting from 2021-01-01. As you can see, the changes correspond nicely with the seasons and are usually only a couple of minutes, but the difference between 02-28 and 03-01 in any year is always 6 six minutes, an obvious outlier.

Here is a link to that spreadsheet and a screenshot of the chart.

https://docs.google.com/spreadsheets/d/1OpQTPeeG1oyb29XctjGekoZE3OVjv7gvykPVcJC7mYw/edit?usp=sharing

image

closed time in 2 days

sdubois

issue commenthebcal/hebcal

Sunrise/sunset changes by large amount between February and March

Thanks again! Fixed in https://github.com/hebcal/hebcal-es6/issues/22

sdubois

comment created time in 2 days

issue closedhebcal/hebcal-es6

Sunrise/sunset changes by large amount between February and March

Created an issue on the wrong project, so reposting here.

Original ticket: https://github.com/hebcal/hebcal/issues/213

closed time in 2 days

sdubois

issue commenthebcal/hebcal-es6

Sunrise/sunset changes by large amount between February and March

Changes deployed.

https://www.hebcal.com/zmanim?cfg=json&start=2021-02-27&end=2021-03-02&geo=zip&zip=07666

Closing this bug. Some URLs may be cached for up to 30 days so if you find something that looks wrong, check the Age HTTP header.

sdubois

comment created time in 2 days

created taghebcal/hebcal-es6

tagv3.9.1

Hebcal, a perpetual Jewish Calendar (ES6)

created time in 2 days

release hebcal/hebcal-es6

v3.9.1

released time in 2 days

issue commenthebcal/hebcal-es6

Sunrise/sunset changes by large amount between February and March

Agreed - the problem was indeed exactly as you describe. I've implemented a fix and have published new npm package @hebcal/core@3.9.1. I will deploy to the website tomorrow.

sdubois

comment created time in 2 days

push eventhebcal/hebcal-es6

Michael J. Radwin

commit sha 6690f93fd74dfc6ca730ffd25dbe70c89790d614

Fix Zmanim inaccuracy for January and February by correctly calculating Julian Date (#22)

view details

push time in 2 days

issue commenthebcal/hebcal-es6

Sunrise/sunset changes by large amount between February and March

Started taking a closer look into the solar-calc library and I think this issue is arising from a bug in how it calculates the Julian date. Here are some examples from Dec 31 2020 to Mar 2 2021.

Dec 31 2459214.5 Jan 01 2459213.5 Feb 27 2459269.5 Feb 28 2459270.5 Mar 1 2459274.5 Mar 2 2459275.5

When you compare these dates to the dates provided by an online conversion tool such as https://www.onlineconversion.com/julian_date.htm you can see that everything from Jan 1 to Feb 28 is incorrect.

sdubois

comment created time in 2 days

startedsoniakeys/meeus

started time in 2 days

startedcommenthol/astronomia

started time in 2 days

issue commenthebcal/hebcal-es6

Sunrise/sunset changes by large amount between February and March

Thanks. We will do some investigation. We are using the solar-calc JavaScript library, and you have provided helpful guidance.

sdubois

comment created time in 2 days

issue commenthebcal/hebcal

Sunrise/sunset changes by large amount between February and March

I tested the hebcal command line program and this problem does not appear to occur.

Since this issue is actually on hebcal-es6, I've opened a new ticket there. https://github.com/hebcal/hebcal-es6/issues/22

Feel free to close this ticket, but the screenshots and information provided here will be useful in getting to the bottom of this issue.

sdubois

comment created time in 2 days

issue openedhebcal/hebcal-es6

Sunrise/sunset changes by large amount between February and March

Created an issue on the wrong project. So reposting here: https://github.com/hebcal/hebcal/issues/213

created time in 2 days

issue commenthebcal/hebcal

Sunrise/sunset changes by large amount between February and March

Digging a little deeper, I calculated sunrise times using the solar-calc nodejs package (https://www.npmjs.com/package/solar-calc) that the Hebcal Zmanim API is using and it appears that this is where the problem is coming from.

Attached is a text file and corresponding chart of the sunrise times for the same date range and location as above, which shows the gradual drift in January and February followed by a significant drop off on March 1.

Thanks to @nkasimer for the chart!

solarcalc_sunrise_teaneck.txt

image

sdubois

comment created time in 2 days

issue commenthebcal/hebcal

Sunrise/sunset changes by large amount between February and March

To add some additional data--I compared a year's worth of sunrise times from hebcal and the Python zmanim library. For most of the year there's fairly consistent error, which I assume is attributable to a combination of rounding, slightly different locations, refractions models, etc. But throughout Jan and Feb the difference increases significantly over time, falling abruptly to a fairly consistent level March through December. The y axis is difference in sunrise times in minutes.

image

sdubois

comment created time in 2 days

issue openedhebcal/hebcal

Sunrise/sunset changes by large amount between February and March

I am noticing a very large change in the time for sunrise (and sunset) between 02-28 and 03-01. This seems to be true in every calendar year, which leads me to believe there is a bug somewhere in the Hebcal code that is causing this. My hunch is that February only having 28 (or 29) days might have something to do with it.

For example, if we look at sunrise in 07666 for 2021-02-28 (https://www.hebcal.com/zmanim?cfg=json&start=2021-02-28&geo=zip&zip=07666) it is 06:36, but for 2021-03-01 (https://www.hebcal.com/zmanim?cfg=json&start=2021-03-01&geo=zip&zip=07666) it is 06:30. That's a difference of 6 minutes in just one day, whereas the differences between the previous day (2021-02-27) is 1 minute and subsequent day (2021-03-02) is only 2 minutes.

I brought this up to @nkasimer who created a spreadsheet of the change in sunrise times for 999 days in 07666 starting from 2021-01-01. As you can see, the changes correspond nicely with the seasons and are usually only a couple of minutes, but the difference between 02-28 and 03-01 in any year is always 6 six minutes, an obvious outlier.

Here is a link to that spreadsheet and a screenshot of the chart.

https://docs.google.com/spreadsheets/d/1OpQTPeeG1oyb29XctjGekoZE3OVjv7gvykPVcJC7mYw/edit?usp=sharing

image

created time in 2 days

startedShopRunner/jupyter-notify

started time in 2 days

issue openedhebcal/hebcal

Shushan Purim when it's Purim Meshulash

It seems that when the 15th of Adar falls on Shabbat, Hebcal treats Shushan Purim as being on Sunday and not on Shabbat. While some Purim stuff is pushed off to Sunday, there are still Shushan Purim things that happen on Shabbat (e.g. Al HaNisim). So when Shushan Purim is on Shabbat Hebcal shows the leyning for Sunday as being the Purim leyning--but in places that celebrate Shushan Purim this is actually read on Shabbat, not on Sunday.

Possible solutions would be to say that, in years like this, both Shabbat and Sunday are Shushan Purim, with leyning only returning for the one on Shabbat (possibly with the haftarah read in places with Shushan Purim, which is the one for Zakhor I believe). Or to have Shabbat be Shushan Purim, and Sunday listed as "Purim Meshulash".

created time in 3 days

issue commenthebcal/hebcal

relative holidays

This is for the Unix CLI app? Or for the website? iCalendar reminders or email reminders?

dsadinoff

comment created time in 3 days

delete branch hebcal/hebcal-es6

delete branch : dependabot/npm_and_yarn/jsdoc-to-markdown-7.0.0

delete time in 3 days

push eventhebcal/hebcal-es6

dependabot[bot]

commit sha dfc70f57045b0161fd736d18e4763bc9d59f4ca7

Bump jsdoc-to-markdown from 6.0.1 to 7.0.0 Bumps [jsdoc-to-markdown](https://github.com/jsdoc2md/jsdoc-to-markdown) from 6.0.1 to 7.0.0. - [Release notes](https://github.com/jsdoc2md/jsdoc-to-markdown/releases) - [Commits](https://github.com/jsdoc2md/jsdoc-to-markdown/compare/v6.0.1...v7.0.0) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 3 days

PR merged hebcal/hebcal-es6

Bump jsdoc-to-markdown from 6.0.1 to 7.0.0 dependencies

Bumps jsdoc-to-markdown from 6.0.1 to 7.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/jsdoc2md/jsdoc-to-markdown/releases">jsdoc-to-markdown's releases</a>.</em></p> <blockquote> <h2>v7.0.0</h2> <p>This is a refresher release - there are no API or functional changes.</p> <h2>Breaking change</h2> <ul> <li>Dropped support for Node.js versions less than v14.</li> </ul> <h2>Minor updates</h2> <ul> <li>Refreshed dependency tree.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/jsdoc2md/jsdoc-to-markdown/commit/eafd4443f098a0d7351ba37bb0064f4a9bce318e"><code>eafd444</code></a> 7.0.0</li> <li><a href="https://github.com/jsdoc2md/jsdoc-to-markdown/commit/363f8bd2061fa38c4c8645b3ce8615a6d3e00776"><code>363f8bd</code></a> drop support for node < v14.. upgrade deps.</li> <li>See full diff in <a href="https://github.com/jsdoc2md/jsdoc-to-markdown/compare/v6.0.1...v7.0.0">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

+1 -1

0 comment

1 changed file

dependabot[bot]

pr closed time in 3 days

PR opened hebcal/hebcal-es6

Bump jsdoc-to-markdown from 6.0.1 to 7.0.0

Bumps jsdoc-to-markdown from 6.0.1 to 7.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/jsdoc2md/jsdoc-to-markdown/releases">jsdoc-to-markdown's releases</a>.</em></p> <blockquote> <h2>v7.0.0</h2> <p>This is a refresher release - there are no API or functional changes.</p> <h2>Breaking change</h2> <ul> <li>Dropped support for Node.js versions less than v14.</li> </ul> <h2>Minor updates</h2> <ul> <li>Refreshed dependency tree.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/jsdoc2md/jsdoc-to-markdown/commit/eafd4443f098a0d7351ba37bb0064f4a9bce318e"><code>eafd444</code></a> 7.0.0</li> <li><a href="https://github.com/jsdoc2md/jsdoc-to-markdown/commit/363f8bd2061fa38c4c8645b3ce8615a6d3e00776"><code>363f8bd</code></a> drop support for node < v14.. upgrade deps.</li> <li>See full diff in <a href="https://github.com/jsdoc2md/jsdoc-to-markdown/compare/v6.0.1...v7.0.0">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

+1 -1

0 comment

1 changed file

pr created time in 3 days

issue openedhebcal/hebcal

relative holidays

feature request: Relative holiday reminders.

e.g. define reminder as "1 week before passover" or "1 hour before every holiday" h/t: request from B.R.

created time in 3 days

startedjart/cosmopolitan

started time in 5 days

startedcli-guidelines/cli-guidelines

started time in 6 days

startedtiangolo/typer

started time in 6 days

issue closedphotopea/UPNG.js

UPNG stacks frames for transparent backgrounds.

In my nodejs project, I take a gif image, break up each frame into png files (using gif-frames), then apply an overlay to them then recombine then into an apng. When the frames have a transparent background it seems UPNG stacks the frames which make the frames stay instead of removing them to display the next one. This is an example of the APNG result when I have cumulative enabled when extracting the frames of the gif then recombine them using UPNG. https://cdn.discordapp.com/attachments/626649734953566218/814236015316434954/1614199393560.png

And here's another if I disable cumulative when extracting the frames then recombine using UPNG. The stacking isn't as bad but it still is keeping data from previous frames. https://cdn.discordapp.com/attachments/626649734953566218/814238946128953354/1614200092424.png

The original gif I used for the above examples is https://media3.giphy.com/media/Wwe6DNWWOvfBbr9Gbc/giphy.gif.

All of the png frames that were extracted from gif-frames look fine when I output them one by one before combining them into a apng image which the only other thing it can be is UPNG.

The result is fine if the image doesn't have a transparent background around the moving parts. https://cdn.discordapp.com/attachments/626649734953566218/814229966102331427/1614197951358.png

closed time in 6 days

BannerBomb