text:
Lost string

@joshbduncan after compilation, the last line is always removed from the original code. Example of my script.
#includepath "lib/" // Libraries folder
#include "base.jsx" // Base small functions
#include "generator.jsx" // Generator functions

function main() {
... // some code
}

// Run script
try {
  main();
} catch (err) {}

I'm getting this
... // included libs

function main() {
... // some code
}

// Run script
try {
  main();

Hmmm, that's weird... Let me look into it and see if I can figure it out.

@creold, so it seems your file has an incomplete last line... My editor is setup to add a blank new line to the end of every file I save so I would have never noticed it. If I just cat out your code with the -e (show invisible characters) flag you can see the last line doesn't have a '$'...  This means there is no new line '\n' character there so my script skips it. I found a deeper explanation here.

It's a simple fix on my end, so I just pushed an update that should work for you...
As a side note, not having that last newline character in your included files would also cause them to bunch up like below.
// base.jsx
// some
// lines
// last line base.jsx// generator.jsx
// some
// lines
// last line generator.jsx
function main() {
  //...
}

Notice how the last line of base.jsx is together with the first line of generator.jsx. That's because that newline character isn't on the last line. I fixed this too by checking if the file has a '\n' character on the last line and if not, the script just adds it in the output.
I recreated your files and tested them on my and all worked for me but try it on your system and let me know if you get the correct results.
$./compile.sh sample/script.jsx
// base.jsx
// some
// lines
// last line base.jsx
// generator.jsx
// some
// lines
// last line generator.jsx

function main() {
  alert(app);
}

// Run script
try {
  main();
} catch (err) {}

@joshbduncan it looks pretty damn good. I compiled two different scripts with libraries. This saves a lot of time

authors: creold joshbduncan

repo: joshbduncan/extendscript-compiler


text:
Question

Is it possible if we search recursively but only for specific blobs?
Eg. I only want to print out what's needed by android.hardware.radio.config@1.0.so

Would the most straightforward solution be to pipe the results to grep?
asop-missing-blobs ... | grep <xxxxx.so>

Thank you very much for the quick response! 👍🙂

source: gharchive/issue

authors: joshchoo laleeroy

repo: joshchoo/aosp-missing-blobs

license: MIT

license_type: permissive

license_source: github-api


text:
How to get the index of wedges

How to find the index of each wedges

for wedgeNumber in 0..<numberOfWedges {
//added
let tapGesture: UITapGestureRecognizer = UITapGestureRecognizer(target: self, action: #selector(self.spinWheelDidSelectValue))
        let wedge: SpinWheelWedge = source.wedgeForSliceAtIndex(index: wedgeNumber)

        //Wedge shape
        wedge.shape.configureWedgeShape(index: wedgeNumber, radius: radius, position: spinWheelCenter, degreesPerWedge: degreesPerWedge)

        //added
        **wedge.layer.addSublayer(wedge.shape)
        wedge.addGestureRecognizer(tapGesture)
        wedge.isUserInteractionEnabled = true**

        //Wedge label
        wedge.label.configureWedgeLabel(index: wedgeNumber, width: radius * 0.9, position: spinWheelCenter, radiansPerWedge: radiansPerWedge)
        wedge.addSubview(wedge.label)

        //Add the shape and label to the spinWheelView
        spinWheelView.addSubview(wedge)
    }

    self.spinWheelView.isUserInteractionEnabled = false

    //Rotate the wheel to put the first wedge at the top
    self.spinWheelView.transform = CGAffineTransform(rotationAngle: -(snappingPositionRadians) - (radiansPerWedge / 2))

    self.addSubview(self.spinWheelView)
}

I've got this functionality working in  this branch . It's accomplished using the new didTapOnWedgeAtIndex delegate function. Going to get it merged into master and published to CocoaPods soon.

repo: joshdhenry/SpinWheelControl


text:
🛑 Loginllama is down

In 7943d28, Loginllama (https://loginllama.app) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Loginllama is back up in a3d660f after 11 minutes.

repo: joshghent/loginllama-status


text:
[WIP] Custom Frameless Menubar (Windows)

Summary:
On MacOS, Guppy has a very nice window decoration integration:

The window controls are cleanly integrated with the sidebar, and all menu controls (File, Edit, etc.) are hidden away in the system bar, as with all Mac applications. On Windows, however, this isn't the case. Windows menus in Electron are very barebones and not very visually appealing. Visual Studio Insiders just recently added the ability to use a more seamless UI by removing the native menubar and adding a themes one in place. I took a page from their book and did the same for Guppy:
Current appearance:

New appearance:

Clearly, this is a stark deviation from the MacOS design, and as such I'm more than willing to find a suitable compromise. The biggest issue we immediately encounter is that Windows UI design dictates that window controls (minimize, maximize, and close) be in square buttons at the top right of the window, so we'll have to do something different from the Mac solution. In addition to this, Windows does not have a system menu bar like Mac, so all menus have to physically live within the application window.
In addition to stylistic changes, there are a few things that need to be improved before this PR is ready for review:

[ ] implement accelerators
[ ] switch active submenus when hovering over a different menu from an active submenu
[ ] find a better way to include menu-item-roles.js from Electron's source
[ ] split FramelessMenu into smaller components
[ ] move FramelessMenu into its own component (?)
[ ] don't break MacOS form or function

Feedback/suggestions are welcomed! Post your ideas, no matter  how rough, here or in the Gitter channel!

Ah interesting! Hm, so I worry about this a bit. My gut reaction is that it may not be worth the added maintenance cost, at least right now.
First, I should say your version looks way nicer :) the default experience on Windows is very lacklustre and I quite like the direction this is going in.
My concern is that it's often a lot of work to perfectly recreate native controls. From the GIF, things look pretty great, but as you point out, there's still a lot to do. Some other things off the top of my head:

Nested menus. I plan on adding a "Switch to:" menu item to Project soon, and it would spawn its own submenu with all the user's projects
Scrolling menus on smaller screens (with the "Switch to", they could conceivably be very long if the user has a lot of projects)
Compliance with screen readers and assistive devices (granted we've thoroughly neglected a11y so far, but I do want to make it work well eventually, and I worry this will make it harder)
Using keyboard shortcuts should flash the menu item it lives within (if this is actually a thing on Windows?)

The native menu is ugly, but it's battle-tested, and we won't get any bug reports about it. I like the idea of not worrying about menu support when I add something new, at least not while our app is still changing rapidly.
I think my instinct is that we do want to do this eventually, but this feels like a late-game thing that we put a lot of effort into to make sure we get it right. Hopefully by then, someone else will have come up with an abstraction that takes care of all of these concerns for us? haha.
Do correct me if I'm wrong in thinking that these concerns would be "our problem" now; it's not entirely clear to me if this theming still uses a native menu under-the-hood (I'm guessing not since we have to reimplement so much, but maybe I'm wrong?)

I totally agree, honestly I was just hacking around and figured I would share. Let's table this until we're at a much more stable spot.
Hey Guppy team in 2019 😁

I totally agree, honestly I was just hacking around and figured I would share. Let's table this until we're at a much more stable spot.

Right, glad to hear it. FWIW I think it looks great and look forward to revisiting =)

When we pick this back up, how about flipping the sidebar to the right side on Windows so we can have the same window control integration as on macOS?

When we pick this back up, how about flipping the sidebar to the right side on Windows so we can have the same window control integration as on macOS?

Hm, I think it's idiomatic to have sidebar navigation on the left-hand side of applications.
Specifically, I stole that layout idea from Slack, so we should check what the Slack windows desktop app does. If other Windows apps have sidebars on the right, I think that's the way to go, but ultimately I'm not too concerned about aligning the window controls with the sidebar.

source: gharchive/pull-request

repo: joshwcomeau/guppy

license: ISC


text:
Fix CircularOutline performance

Related Issue: closes #225
Summary:
Our  component triggered an immediate re-render after mount, since it needed to read the SVG created by React. This was causing performance issues (Stuttery modal opens, mostly). It was also causing a weird issue where the outlines would disappear sometimes, due to a Chrome bug (most likely).
This change creates a new division between two types of outlines:

Truly circular ones, like the ones used in ProjectIcon. Round circles with an outline
Outlined buttons, which are really just rounded rectangles

For the former, the behaviour is unchanged. This is possible because we know the width/height of those icons, so we can use geometry to work out the path length instead of relying on the DOM.
While it may be possible to do the same for rounded rectangles, we don't currently have any way of knowing the width of buttons, and because our buttons can change widths dynamically, it felt like too much trouble. Instead, I went for a new approach: using a background gradient.
Essentially now the StrokeButtons have a "background" layer, and a "foreground" layer that holds the actual button. The background layer has a solid background gradient, but the foreground layer has a background colour that overrides it, and some padding so that the background layer is larger. Because of this, it appears to just be an outline.
The downside is there's no clear way to do the "self-drawing" effect on click... but I don't feel too sad about it. Instead I added a simple fade in/out. The only place that uses this effect in the app is the project-type selection in the new project wizard, and I actually prefer the new effect here, it's less "busy":

(oh, also the random generator button uses it too, but I want to replace it anyway. Created a new issue, #264)
Profile diff:
Here's the difference in speed when opening the "Project configuration" modal:
Before:

After:

This makes the modal feel like it opens more quickly. I imagine the difference is even more stark on less-powerful machines (I work from an iMac Pro)
GIFs:
Here's the storybook for the new stories:

Actually @mathieudutour, I really wanna get this merged so that it (potentially) unblocks #213, but feel free to add comments anyway, I can always address them in a followup PR.


text:
Invalid XHTML

Hi,
First of all: Thanks for your work, this is indeed awesome. I did something similar for our project documentation, but your solution is much cleaner and more comprehensive. I immediately adopted it, see our user guide for an example. I did some minor changes, mostly to the sidebar, maybe you are interested in some of those.
Anyway, the main issue I had was invalid XHTML markup: If you run your site through the W3C validator you'll notice a couple of issues you might want to fix.
Thanks,
Daniel

Thanks for pointing that out, it seems like I have mixed in some html5 by accident...
Thanks for sending me a link of your documentation, it's always helpful to see what others do with the theme!
I like the style of the arrows in the sidebar! It seems like the adjustments that you made don't work for the dark theme, though:

If you don't want / don't care about dark mode you will be able to disable it in the upcoming release by setting
<html class="light-mode">

Thanks for spotting, fixed. Only tested dark mode on mobile.
For the arrows I simply override the icon used in navtree.js by adding a snippet to my header.html:
<script type="text/javascript">
  var arrowRight = '▷';
</script>

authors: dsieger jothepro

repo: jothepro/doxygen-awesome-css


text:
rename slave to agent

per https://github.com/joyent/mesos-dockerfiles/issues/9, and good taste.

LGTM.

Are these the same "slaves" as mesos "slaves"? People do recognize them by that name. This reminds me that someone asked "how does this Mesos's handle slaves on Triton?" Is the datacenter one big slave?

@xer0x: yes, but they're now called "agents" in proper Mesos terms.
The implementation in the blog post is a single agent per data center (actually, a single agent per docker host).

authors: misterbisson tgross xer0x

repo: joyent/mesos-dockerfiles

license_source: bigquery


text:
documentation request: .env

Can you provide an example of what to put in the .env file?

I found some good parallel documentation here: https://devcenter.heroku.com/articles/config-vars
So, I can see the likely structure of the .env file, along with a reminder to add .env to .gitignore

Closed by 3687e1b124653f8b77b4b76d6558feb8b8715d62. Reference to tests.py to see all supported formats.

Thanks for this!  It helped me choose django-dotenv over alternatives because of the support for bash-compatible files.  Would be nice to have some examples in the README though.

@merwok PRs are welcome :)

authors: jpadilla merwok mroswell

repo: jpadilla/django-dotenv

license: mit


text:
Can we assume this has been abandoned?

I don't see any PRs getting merged, and it looks like the last update was 5 years ago.  Is this project officially dead?

Sadly, it is more or less because I've had no capacity to manage it. If you're looking to make changes I have added contributors in the past to steward through PRs and issues.

Are there any known forks working with php 8 ?

Are there any known forks working with php 8 ?

https://github.com/php-activerecord/activerecord

authors: brandondrew jpfuentes2 karimzah nicolasvac


text:
Prefetching rows from remote source

Is there a way to prefetch rows from a remote source?
It seems that setting setDataListener gets called whenever the viewport changes. When scrolling this generates a lot of calls to the server. What is the best way to implement a caching mechanism to load data in pages (e.g. load 100 rows instead of just the 25 of the viewport) and have the table generate a call only when needed, or when approaching the edge of the prefetched data?

regular-table does not cache/keep any data, even for just the visible viewport, once rendered this data is discarded.  This is by design, and preserves proper separation from the data model.  If you have a specific prefetch strategy in mind, it is trivial to implement a cache pattern within a setDataListener() callback data model, something like so:
async function dataListener(x0, y0, x1, y1) {
    if (!cache.has(x0, y0, x1, y1)) {
        const data = await getDataFromServer(...embiggenViewport(x0, y0, x1, y1));
        cache.set(x0, y0, data);
    }
    return cache.get(x0, y0, x1, y1);
}

Future renders will block until a page request to this callback is complete, so you can trade off page-boundary for intra-cache performance as desired.
If you are interested in a more fully-featured data model, rather than the bring-your-own approach of regular-table, check out perspective, a complete WebAssembly data model and query engine for regular-table

Thank you for your repsonse! Perspective is great and I was actually asking in that regard. It seems that the Perspective dataListener in case of a remote view reloads the viewed records from the remote server which causes a lot of roundtrip data sent over the wire. I was looking into the best way to implement such caching with Perspective's remote view capabilities.
I was asking on this repo since it seems the dataListener implementation for Perpsective resides here.
Does this functionality already exist within Perspective?
Any pointers on implementation would be appreciated so I can try to produce a PR.

No, perspective-python's virtual mode does not do this;  scroll performance is substantially better without it for the reason stated below.  However, it is much more common to run perspective both on the server and client (via the perspective.js WebAssembly library), in which case the entire data set is downloaded via Apache Arrow to the browser and loaded locally where scroll "roundtrip" is not an issue.

It seems that the Perspective dataListener in case of a remote view reloads the viewed records from the remote server which causes a lot of roundtrip data sent over the wire.

All virtual data models do this, even if you increase the "page size".  I think you may misunderstand how regular-table's scrolling works, it does not make a request for every scroll row;  rather, it fires a scroll repaint at the current scroll position at the moment the previous render frame is complete, which may be many thousands of rows after the previous frame, or perhaps before (or diagonally!), depending on where the user has scrolled.  Doing nothing other than increasing the page size makes your request 1/N as frequent but block for N times a long, except you no longer can make requests for the next draw page while rendering the previous one, leading to overall lower average scroll frame rate.

authors: texodus zalmane

repo: jpmorganchase/regular-table


text:
Add logo

Adds a regular project logo

Lmao

authors: texodus timkpaine


text:
input - added bordered input variant

Part of #3456

@ThusharaJ07 there's an issue with the activation line when Corner = Round both for full and bottom bordered components (for both Input and Multiline). At the moment it doesn't follow the rounded corner.

Replaced by #3537

repo: jpmorganchase/salt-ds


text:
Install docs update

Thanks for this project. Just thought I'd let you know the 'bower install' command is missing from the getting started section of the docs. Also, bower install places the components in a 'bower-components' directory under the 'public' directory. The code references them being in 'app/lib/. Not sure if that's something strange about my bower setup, but you need to run bower install, move the 'bower-components' directory inside the public directory and rename it to 'lib'. Otherwise, the app won't run (all kinds of missing files, etc.)
Again, thanks for this contribution. Cheers.

Guess you need to be running 'grunt' from inside the app directory- that would fix the second part of the problem above. Might want to mention that as well.

Feel free to send a PR and help other people.
On Feb 26, 2016 8:58 AM, "hairgamiMaster" notifications@github.com wrote:

Guess you need to be running 'grunt' from inside the app directory- that
would fix the second part of the problem above. Might want to mention that
as well.
—
Reply to this email directly or view it on GitHub
https://github.com/jpotts18/mean-stack-relational/issues/48#issuecomment-189338302
.

hi @hairgamiMaster
If you look closely at step# 3 in the instructions in README.md, you'll find that doing npm install does three things:

runs npm install
runs bower install
copies development.json5.sample and production.json5.sample files to development and production.json5
runs grunt copy

As for the presence of the lib folder, it could be removed in a future update to use bower components directly. I am looking into it. If you come up with a PR sooner, I'll be only more glad.

authors: chaudhryjunaid hairgamiMaster jpotts18


text:
Propose adding new config entry constructor

This method allows us to more simply create config values using mostly strings and allows for the following paramters:

group - how to group the value in the config
name - name of the parameter
defaultValue - the default value of the parameter
description - a short description of what the parameter does
acceptableValues - a list of acceptable or possible values you can use
serverSync - whether or not this parameter is enforced server side or client side

Note: Instead of breaking the groups into server synced and client synced, this new constructor simply adds either "[Synced with Server]" or "[Not Synced with Server]" to the end of the description.
Willing to take suggestions or make tweaks or include additional tags.
Before:
        public static void CreateConfigs(BaseUnityPlugin plugin)
        {
            allowed = plugin.Config.Bind("SpiritPylon (Server Synced)", "SpiritPylonAllowed",
                true, new ConfigDescription("Whether making a Spirit Pylon is allowed or not.", null,
                new ConfigurationManagerAttributes { IsAdminOnly = true }));

            craftingCost = plugin.Config.Bind("SpiritPylon (Server Synced)", "Spirit Pylon Build Costs",
                DefaultRecipe, new ConfigDescription("Materials needed to build Spirit Pylon. None or Blank will use Default settings.", null,
                new ConfigurationManagerAttributes { IsAdminOnly = true }));

            sightRadius = plugin.Config.Bind("SpiritPylon (Server Synced)", "SpiritPylonSightRadius",
                30f, new ConfigDescription("How far a Spirit Pylon can see enemies.", null,
                new ConfigurationManagerAttributes { IsAdminOnly = true }));

            ghostDuration = plugin.Config.Bind("SpiritPylon (Server Synced)", "SpiritPylonGhostDuration",
                30f, new ConfigDescription("How long a Spirit Pylon's ghost persists.", null,
                new ConfigurationManagerAttributes { IsAdminOnly = true }));

            delayBetweenGhosts = plugin.Config.Bind("SpiritPylon (Server Synced)", "SpiritPylonDelayBetweenGhosts",
                5f, new ConfigDescription("How long a Spirit Pylon must wait before being able to spawn another ghost.", null,
                new ConfigurationManagerAttributes { IsAdminOnly = true }));

            maxGhosts = plugin.Config.Bind("SpiritPylon (Server Synced)", "SpiritPylonMaxGhosts",
                3, new ConfigDescription("The maximum number of ghosts that a Spirit Pylon can spawn.", null,
                new ConfigurationManagerAttributes { IsAdminOnly = true }));
        }

[SpiritPylon (Server Synced)]

## Whether making a Spirit Pylon is allowed or not.
# Setting type: Boolean
# Default value: true
SpiritPylonAllowed = true

## Materials needed to build Spirit Pylon. None or Blank will use Default settings.
# Setting type: String
# Default value: Stone:15,Wood:15,BoneFragments:15,SurtlingCore:1
Spirit Pylon Build Costs = Stone:50,Wood:50,BoneFragments:100,SurtlingCore:5

## How far a Spirit Pylon can see enemies.
# Setting type: Single
# Default value: 30
SpiritPylonSightRadius = 30

## How long a Spirit Pylon's ghost persists.
# Setting type: Single
# Default value: 30
SpiritPylonGhostDuration = 60

## How long a Spirit Pylon must wait before being able to spawn another ghost.
# Setting type: Single
# Default value: 5
SpiritPylonDelayBetweenGhosts = 5

## The maximum number of ghosts that a Spirit Pylon can spawn.
# Setting type: Int32
# Default value: 3
SpiritPylonMaxGhosts = 3

After:
        public static void CreateConfigs(BasePlugin plugin)
        {
            allowed = plugin.ModConfig("SpiritPylon", "SpiritPylonAllowed",
                true, "Whether making a Spirit Pylon is allowed or not.", "true or false", true);

            craftingCost = plugin.ModConfig("SpiritPylon", "Spirit Pylon Build Costs",
                DefaultRecipe, "Materials needed to build Spirit Pylon. None or Blank will use Default settings.",
                "<Prefab1>:<quantity>[[,<PreFab2>:<quantity>], ...]]", true);

            sightRadius = plugin.ModConfig("SpiritPylon", "SpiritPylonSightRadius",
                30f, "How far a Spirit Pylon can see enemies.", "1 to 100", true);

            ghostDuration = plugin.ModConfig("SpiritPylon", "SpiritPylonGhostDuration",
                30f, "How long a Spirit Pylon's ghost persists.", "1 or more seconds", true);

            delayBetweenGhosts = plugin.ModConfig("SpiritPylon", "SpiritPylonDelayBetweenGhosts",
                5f, "How long a Spirit Pylon must wait before being able to spawn another ghost.",
                "1 or more seconds", true);

            maxGhosts = plugin.ModConfig("SpiritPylon", "SpiritPylonMaxGhosts",
                3, "The maximum number of ghosts that a Spirit Pylon can spawn.", "1 or more", true);
        }

[SpiritPylon]

## Whether making a Spirit Pylon is allowed or not. [Synced with Server]
# Setting type: Boolean
# Default value: true
# Acceptable value range: true or false
SpiritPylonAllowed = true

## Materials needed to build Spirit Pylon. None or Blank will use Default settings. [Synced with Server]
# Setting type: String
# Default value: Stone:15,Wood:15,BoneFragments:15,SurtlingCore:1
# Acceptable value range: <Prefab1>:<quantity>[[,<PreFab2>:<quantity>], ...]]
Spirit Pylon Build Costs = Stone:50,Wood:50,BoneFragments:100,SurtlingCore:5

## How far a Spirit Pylon can see enemies. [Synced with Server]
# Setting type: Single
# Default value: 30
# Acceptable value range: 1 to 100
SpiritPylonSightRadius = 30

## How long a Spirit Pylon's ghost persists. [Synced with Server]
# Setting type: Single
# Default value: 30
# Acceptable value range: 1 or more seconds
SpiritPylonGhostDuration = 60

## How long a Spirit Pylon must wait before being able to spawn another ghost. [Synced with Server]
# Setting type: Single
# Default value: 5
# Acceptable value range: 1 or more seconds
SpiritPylonDelayBetweenGhosts = 5

## The maximum number of ghosts that a Spirit Pylon can spawn. [Synced with Server]
# Setting type: Int32
# Default value: 3
# Acceptable value range: 1 or more
SpiritPylonMaxGhosts = 3

ModConfig Constructor being used in BasePlugin:
        public ConfigEntry<T> ModConfig<T>(string group, string name, T default_value,
            string description = "", string acceptableValues = "",
            bool serverSync = false, params object[] tags)
        {

            // Create extended description with list of valid values and server sync
            ConfigDescription extendedDescription =
                new ConfigDescription(
                    description + (serverSync
                        ? " [Synced with Server]"
                        : " [Not Synced with Server]"),
                    new AcceptableValueList<string>(acceptableValues),
                    new ConfigurationManagerAttributes { IsAdminOnly = serverSync },
                    tags);

            var configEntry = Config.Bind(group, name, default_value, extendedDescription);

            return configEntry;
        }

If this is acceptable, I will do the work of converting all current config values to use ModConfig and test it.

@Dracbjorn I like it, please go ahead. Thank you & good work

license: Unlicense


text:
Changing the selected day in week view by clicking anywhere.

Hello!
Using a week view, I want to be able to select a day by clicking on that day anywhere (not only limited to header).
While in month view providing a custom component dateCellWrapper does the job, in week view it does not work.
I noticed in week view, the cells are owerlapped by another component - eventContainerWrapper.
So I had to customize this component:
<Calendar
  onDrillDown={onDrillDown}
  components={{
        eventContainerWrapper: EventContainerWrapper
  }}
...

const EventContainerWrapper = ({ children, ...props }) => {
    return (
        React.cloneElement(React.Children.only(children), {
            onClick: () => {
                onDrillDown(props.slotMetrics.groups[0][1])
            },

        })
        )
    }

  const onDrillDown = (x) => {
    setSelectedDate(moment(x));
  };

I wonder if there is a better solution to my need. If not, at least in EventContainerWrapper, is there a better way to get information about what is the date of day I clicked into, than how I'm getting it now?

The is selectable prop for that.  prop explanation in doc
Whenever a slot is selected on any views the onSelectSlot is fired.
somthing like this
<Calendar
    selectable={true}
    onSelectSlot={(SlotInfo) => {
        /**
         slotInfo : {
            start: Date,
            end: Date,
            slots: Array < Date >,
            action: "select" | "click" | "doubleClick",
            bounds: ? { // For "select" action
                x: number,
                y: number,
                top: number,
                right: number,
                left: number,
                bottom: number,
            },
            box: ? { // For "click" or "doubleClick" actions
                clientX: number,
                clientY: number,
                x: number,
                y: number,
            },
        }
            */
        setSelectedDate(SlotInfo.bounds.x);
    }}
/>

authors: bilobom justdvl

repo: jquense/react-big-calendar


text:
Path to ESTree spec in  leads to 404

The reference to spec.md on the gh-pages branch is a dead link, as the ESTree project renamed spec.md to es5.md as of this commit.

The README.md file also has a link to spec.md.

repo: jquery/esprima


text:
[core] Enum values are printed in lowercase which is confusing

Task List

[x] Steps to reproduce provided
[ ] Stacktrace (if present) provided
[ ] Example that reproduces the problem (link to git repository is ideal)
[x] Full description of the issue provided (see below)

Steps to Reproduce

git clone https://github.com/jreleaser/helloworld-java-bin
Execute jreleaser config

Expected Behaviour
assemble section should look like this
assemble:
    enabled: true
    active: ALWAYS
    javaArchive:
        helloworld:
            enabled: true
            exported: true
            active: ALWAYS
            stereotype: CLI
            archiveName: {{distributionName}}-{{projectVersion}}
            formats:
                ZIP
            executable:
                name: helloworld
                windowsExtension: bat
            mainJar:
                path: target/{{distributionName}}-{{projectVersion}}.jar
            java:
                mainClass: org.jreleaser.examples.HelloWorld
            templateDirectory: src/jreleaser/assemblers/helloworld/java-archive
            fileSets:
                fileSet 0:
                    input: .
                    includes:
                        LICENSE

Actual Behaviour
assemble section looks like this instead
assemble:
    enabled: true
    active: always
    javaArchive:
        helloworld:
            enabled: true
            exported: true
            active: always
            stereotype: cli
            archiveName: {{distributionName}}-{{projectVersion}}
            formats:
                zip
            executable:
                name: helloworld
                windowsExtension: bat
            mainJar:
                path: target/{{distributionName}}-{{projectVersion}}.jar
            templateDirectory: src/jreleaser/assemblers/helloworld/java-archive
            fileSets:
                fileSet 0:
                    input: .
                    includes:
                        LICENSE

Environment Information

Operating System: N/A
JReleaser Version: 1.5.0
JDK Version: N/A

🎉 This issue has been resolved in v1.5.1 (Release Notes)

repo: jreleaser/jreleaser


text:
Add Article for Hello World in Verilog

Just merged: #96.

Added: https://github.com/jrg94/sample-programs/commit/f4ab4414b99d97f3e78ac18adecabc349fc3337c


text:
sections support

Following along with several issues elsewhere on github, and would like to use trace-mapping as a (transitive) dependency in ts-node.
https://github.com/terser/terser/pull/1164#issuecomment-1068354694
Am I understanding correctly, that this library is missing support for sections?  Can this issue be used for tracking progress on that?

It's implemented via AnyMap. I hadn't documented it because I considered it to be a niche API, but I'd be happy to accept a doc PR if you want to contribute.

I see, does this mean consumers of the API must take special care to leverage it?  Or can a consumer use the API as they otherwise would?  I'm admittedly unfamiliar with sections and what it means.  I naively assume that consumers of this API don't necessarily need to care whether or not a sourcemap uses sections.

I naively assume that consumers of this API don't necessarily need to care whether or not a sourcemap uses sections.

Correct. AnyMap can take any form of sourcemap, and will return a regular TraceMap instance. Eg, if a regular sourcemap is passed to AnyMap, it immediately returns with a new TraceMap, and if a sectioned sourcemap is passed, it converts from the section offsets into a regular sourcemap and returns that as a new TraceMap.

Nice, thanks for the explanation.  I hope to have time to try it soon.

authors: cspotcode jridgewell

repo: jridgewell/trace-mapping


text:
DATETIME and NUMBER functions

Hey @jrmajor, thanks again for your amazing work on this library.
Almost 2 years ago I began my own fluent-php implementation, which was basically a 1:1 port of the JS implementation. It was untested and I never published it or used it in production, so I'm glad you started work on this one which appears to have a much improved architecture and more intent to maintain than I ever had.
However, my implementation did have some additional functionality – specifically, I had implementations of the NUMBER and DATETIME builtin functions. I wanted to share the source code with you now in hope that it can be of use to you.
https://github.com/tobyzerner/fluent-php
Note that the function implementations have a number of caveats, documented in the README:

PHP includes the NumberFormatter and IntlDateFormatter classes, but these lack some of the functionality of Intl.NumberFormat and Intl.DateTimeFormat, and thus the full API for the built-in functions cannot be supported. Specifically:

In NUMBER, the currencyDisplay option is not supported.
In DATETIME, no options are supported except for timeZone. However, the experimental dateStyle and timeStyle options are supported.

But still, I think they're better than nothing. Fluent isn't nearly as useful without them.
On the side, it also had an implementation of DOM Overlays from fluent-dom (also in the form of a 1:1 port), which may also be useful:
Overlay::translateHtml(
    '

',
    [
        'value' => 'Hello, !',
        'attributes' => ['title' => 'Hello']
    ]
);
// →
Hello, !

Thank you for sharing your implementation! I'll try to find some time to work on built-in functions soon. I will also think about DOM overlay, but first I want to tag v1 :)

@tobyzerner I want NUMBER and DATETIME implementations to be complete, so I need to recreate Intl.NumberFormat and Intl.DateTimeFormat in PHP. I'm still working on it, but it will probably take some time.

Awesome! Very ambitious - thank you for putting in the work.

Hi @jrmajor, thanks for your work so far! Can I bother you for a little progress update?

Sure! I've just released https://github.com/jrmajor/fluent-php/releases/tag/v0.4.0 and https://github.com/jrmajor/laravel-fluent/releases/tag/v0.1.4 with NUMBER() support. DATETIME() seems even more complex — I'll see what I can do about it :).

Hey @jrmajor - do you have any thoughts about support for partially-formatted variables?

@tobyzerner They're already supported:
$bundle = (new FluentBundle('en-US'))->addFtl('test = { NUMBER($arg, minimumFractionDigits: 1) }');

// This will return '12345.0', respecting both minimumFractionDigits and useGrouping options.
$bundle->message('test', arg: (new FluentNumber(12345))->setOptions(['useGrouping' => false]));

After a few failed attempts, I decided to give up on the DATETIME() support until some PHP library with JS-compatible date formatter API comes up. For now, I would recommend providing a simplified replacement function based on IntlDateFormatter.
@tobyzerner, I'm sorry.

No worries @jrmajor! Seems like an extremely difficult thing to build.
FYI I have just launched my new project using this lib. Thanks for making it possible to use Fluent in PHP. For dates, mostly I am using github/relative-time-element anyway, otherwise I am using Carbon's isoFormat and passing the result into Fluent as a text argument. It's not quite as powerful for translators but works well enough for now.

Hey @tobyzerner, recently @ramsey started working on https://github.com/php-ecma-intl/ext, which would allow me to implement DATETIME(). I'm unsure whether it will work for your particular use case, as you may not want to introduce such dependency to a self-hosted product. Anyway, I'll see what can be done as soon as he tags a release.

Thanks for letting me know! As you say, this probably won't be suitable for my use-case, but it's good to know that this is being worked on.

Hi! 👋🏻
I'm developing ecma_intl to be a 1:1 port of ECMA-402 to PHP.
@jrmajor, the first tagged release will be a 0.1.0 version and will only include the Locale class and supporting features. Later releases will follow that include datetime and number formatting, etc.
@tobyzerner, what's your use-case?

@ramsey A self-hosted app, meaning that having a hard dependency on a non-default PHP extension probably isn't a good idea, unfortunately 😔

Understood. There's might be some interest in making it part of the core, so we'll see. 😄

authors: jrmajor ramsey tobyzerner

repo: jrmajor/fluent-php


text:
Respond to https://hypothes.is/a/iziCYs3VEem5ghteNR0YQA

Respond to hypothes.is annotation iziCYs3VEem5ghteNR0YQA on https://jrnold.github.io/r4ds-exercise-solutions/iteration.html (user: acct:Amaks@hypothes.is, created: 2019-09-02T23:01:05.749985+00:00, updated: 2019-09-02T23:01:05.749985+00:00)

The way this is written could be somewhat confusing to a reader, in my opinion, although the code makes the order of the functions clearer..
Suggestion:
If we wanted a numeric vector, we could combine the map() followed with the flatten_dbl(),

Link: https://hyp.is/iziCYs3VEem5ghteNR0YQA/jrnold.github.io/r4ds-exercise-solutions/iteration.html

Already fixed.


text:
Fix signin command in cli error message

minor fix

great catch thanks!

repo: jrudio/go-plex-client


text:
Response from durable rules

Hi,
I'm getting started with this using ruby, coming from a drools background.  I'm relatively new to ruby and durable rules.
The kind of thing i'm struggling to figure out looking at the  documents is how to return the goal achieved in the service response.  The examples are only giving  a print statement to console.  I'm interested in composing an outcome and sending this as a response .
at the moment   if  i call
http://localhost:4567/test/events
with post  body
{"subject": "World"}
I get a response
{"outcome":0}
I want to return the full "hello world string as part of this service.  And or in cases have a separate object which i start adding to when rules are running and then return this object at the end.
appreciate this is not an issue with the rule engine, but there is something lacking with documentation

Hi, thanks for posting the question. Posting events and asserting facts is asynchronous. That is, in the example you have, when the http post completes, the event has been queued, but not necessarily processed. It is possible to save the outcome of the rule in the ruleset context and poll for it. The doc has a section describing this process:
https://github.com/jruizgit/rules/blob/master/docs/rb/reference.md#state
Hope this helps,

@jruizgit I am trying to use durable_rules in one of my projects. After validation, I need to know which rules were failed and which were passed. Is there a way to retrieve that?

Looks like this is the method you want to use to get the state: https://github.com/jruizgit/rules/blob/901749ec1905318025635da3bc289d968e487024/librb/durable.rb#L46-L48

polling is mentioned here... is there a way to poll the facts of a session at a given point in time?  That is, after the facts have been asserted or posted, can the session be queried for the facts that exist (including facts derived from rules that triggered)?  As mentioned here, print statements are the example, it would be nice to be able to return or insert general objects from a triggered rule and query for them.
Thanks for this package, it is very helpful.

repo: jruizgit/rules


text:
(feature request) save query

Hi Joaquin,
great tool, it is working well! Kudos.
I have quite complex queries, with a lot of headers, etc.
Now each time I re-start working on them, I have to fill in all the fields anew.
Please consider a "save query" option.
Into the browser memory?
OR, even better, then the queries can be shared among people:
Take all the inputs, and once I press the "execute" button, it redirects to a new page, where all my inputs are urlencoded, and attached to a RESTMAN url, like:
chrome-extension://aahelpfcopefplnmnphdochceilphfeb/index.html?headers=content-type|application/json&method=post&url=https://api....&....
Then I could store that url manually, and even send it to other users of RESTMAN.
What do you think?
Sunny greetings to Argentina!

Hey! That's a great feature!!

Now each time I re-start working on them, I have to fill in all the fields anew.
Please consider a "save query" option.

When you say you have to fill in all the fields, how is this different from clicking on the history item? I mean if you have made the request before it should load all the details of the request.
The "share request" is certainly interesting!
Right now I can't commit to a date but I'll work on this as soon as possible! :)
Thanks for your feedback!!

authors: altsheets jsargiot

repo: jsargiot/restman


text:
possible to support a two-argument ppgen.arg eg ppgen.arg(param text, default_value anyelement)?

I came across pggen today and I'm enjoying it so far - I like static queries and the vision here.
One pain point though is that I would like to be able to directly execute my sql queries for ease of testing and prototyping -- and I need some way of supplying appropriate values and value_types to ppgen.arg().
I initially did something like this
CREATE SCHEMA pggen;
CREATE OR REPLACE FUNCTION pggen.arg(param text)
  RETURNS text
  AS $$
  SELECT
    CASE WHEN param = 'rental_id' THEN
      '1'
    WHEN param = 'Limit' THEN
      '3'
    WHEN param = 'Offset' THEN
      '0'
...
    WHEN param = 'Sort' THEN
      'price'
    WHEN param = 'SortDirection' THEN
      'ASC'
    END
$$
LANGUAGE sql;

The idea there was to define a fake pggen.arg() method which returns different string values based on the provided param.  The workflow was when I wanted to change one of the parameters while interactively prototyping a query, I'd just change the value in the fake definition of pggen.arg() and then re-execute the query.
There are two major problems with that:

its pretty annoying to re-define the stub method whenever I want to change the value of an interactively defined parameter
more importantly -- its only possible to return a string value this way.  There are obviously arguments that I want to define which have other postgres types

I'm wondering if we could add support to pggen for a two argument version of pggen.arg  -- like below:
CREATE OR REPLACE FUNCTION pggen.arg(param text, default_value anyelement)
  RETURNS anyelement
  AS $$
  SELECT
    default_value
$$
LANGUAGE sql;

This would allow for writing queries that are consumable by pggen but which cann still be executed interactively for ease of development and feedback speed.
-- name: SearchFoo :many
select * from foo where id = any(pggen.arg('matching_ids', '{1,4,9}'::integer[])`

For the above, when the query is run interactively pggen.arg(text, integer[]) will be invoked and the integer[] value will be returned, meanwhile the compiled query will take the value of the argument from the corresponding prepared statement placeholder as normal.

One pain point though is that I would like to be able to directly execute my sql queries for ease of testing and prototyping -- and I need some way of supplying appropriate values and value_types to ppgen.arg().

The alternative syntax for params suggested in https://github.com/jschaf/pggen/issues/42 is slowly growing on me.
As for what I personally use: some editors allow you to define a regexp for a customizable parameter syntax. Here's how to do it for IntelliJ-based editors:
Run pggen queries directly
Instead of copying queries, you can run pggen queries directly against any IntelliJ datasource by defining a regexp to match pggen.arg('val'). IntelliJ calls these User Parameters. Typically, these look like ? or :name but IntelliJ is flexible enough to match the pggen syntax.
First, create a new parameter pattern with the regexp.
pggen.arg\('([^']+)'\)

Does that approach work for you?

Does that approach work for you?

I appreciate the workflow info!  The jetbrains rewrite rule seems like an 'ok' workaround but that approach preserves a number of pretty annoying papercuts ...

Suitable values for potential arguments live outside the codebase in the ide -- so you can't just quickly and easily document/preserve/re-enter any arbitrary executable context for any arbitrary sql query in your codebase ...  I want to be able to open up a random sql file, leave a little turd inside the file which describes some appropriate values for all the arguments, and immediately re-execute the sql to inspect the results
errors with column characters become useless because the sql executed doesn't match what was written (I believe this applies to both the ide rewrite workflow and the proposed :arg syntax)
for :arg syntax, writing not valid sql will produce experience degradation in some editors or in terms of consumption of the sql from some tools (formatters/beautifiers?).  Maybe that syntax extension is common enough that tools tend to support it, but in my opinion, anything that leads to the sql being not just valid sql is strictly worse than alternative approaches which preserve the approach where the author always writes valid sql ...

As I consider your suggestion and think about the two arg approach again, I'm even more leaning towards the two arg approach ...
Consider a workflow like this:
CREATE TYPE rental_user AS (
  id integer,
  first_name text,
  last_name text
);

CREATE OR REPLACE FUNCTION pggen.arg(param text, default_type_or_value ANYELEMENT)
  RETURNS anyelement
  LANGUAGE plpgsql
  AS $func$
BEGIN
  IF param = 'name' THEN
    RETURN 'bob';
  ELSIF param = 'age' THEN
    RETURN 12;
  ELSIF param = 'user' THEN
    RETURN ROW(1,
      'bob',
      'lasty')::rental_user;
  ELSIF param = 'ids' THEN
    RETURN '{1,2}'::integer[];
  ELSIF param = 'sort' THEN
    RETURN 'schemaname';
  ELSIF param = 'sort_direction' THEN
    RETURN 'ASC';
  ELSIF param = 'limit' THEN
    RETURN 6;
  ELSE
    RETURN default_type_or_value;
  END IF;
END
$func$;

SELECT
  pggen.arg('name', NULL::text) AS name,
  pggen.arg('age', NULL::integer) AS age,
  pggen.arg('user', NULL::rental_user) AS user,
  pggen.arg('ids', NULL::integer[]) AS ids,
  pggen.arg('sort_direction', NULL::text) AS sort_direction
FROM
  pg_tables
ORDER BY
  CASE WHEN pggen.arg('sort', NULL::text) = 'schemaname' THEN
    schemaname
  ELSE
    tablename
  END
LIMIT pggen.arg('limit', NULL::bigint);

valid sql so the universe of sql analysis tools should tend toward behaving and things like column numbers in error messages should match up
easy to define a parameter value set next to the query definitions themselves that can be preserved as part of the codebase
shouldn't modify existing behavior or philosophy of tool
flexible -- for example developer could define helper functions for convenience of their own interactive use ... CREATE OR REPLACE FUNCTION pggen.default_user() returns rental_user ...

This approach could maybe also provide a solution for -- https://github.com/jschaf/pggen/issues/85 ...  I think it could make sense for the type inference for the two argument ppgen.arg() to always map the argument to a go nullable type -- and if nil is provided to generate a query that resolves to the default value supplied in second argument ...
eg -- select pggen.arg('foo', 1::integer) maps foo to the go type *int and compiles to the the query select coalesce(:1, 1) ...

Funnily enough, I initially prototyped support for pggen.arg with a default value but never exposed it: https://github.com/jschaf/pggen/commit/363cf19563c6f8fcc9cdc59b20b7d27fc81e2f85
The reasons I haven't implemented pggen.arg with a default:

Nil-everything: For the two-arg approach of pggen.arg('limit', NULL::bigint), we'd have to make every input arg a non-pointer. Otherwise, for data types like int, there's no way to distinguish between the unset and a zero value. I took inspiration from protobuf where primitive values don't have a nil value, just a zero value.

Parsing: To do it properly would require a better parser. Simple things like pggen.arg('foo', 2) are easy enough. But it's not clear where to draw the line. Should pggen.arg support any scalar value? pggen.arg('foo', exists(SELECT 1 FROM ...)). Currently, pggen's "parser" only recognizes strings, semicolons, and comments--which is the minimum syntax needed to identify a complete query.

It turned out to be easy enough to work around in SQL.

SELECT
  nullif(pggen.arg('foo'), ''),                          -- to use a null default value
  coalesce(nullif(pggen.arg('foo'), ''), 'default_value) -- to use a default value

Suitable values for potential arguments live outside the codebase

I think using the nullif trick embeds the default value in the query.
At the design level, I'm wary of expanding Pggen's syntax to support interactive use-case. I'm sympathetic since I've done regexp surgery to convert pggen queries to support interactive queries.
Aside
I don't think the following helps the interactive use-case but it gives an idea for pggen's future direction:
Long term, I think the way forward is more user-configurable type-mappers at three levels. At present, type overrides are only supported at the invocation level.

invocation level
query level
column level

Then a user can use different type mappers to support null or default values. I should start a pggen "v2" tracking ticket for these ideas.

Nil-everything: For the two-arg approach of pggen.arg('limit', NULL::bigint), we'd have to make every input arg a non-pointer. Otherwise, for data types like int, there's no way to distinguish between the unset and a zero value. I took inspiration from protobuf where primitive values don't have a nil value, just a zero value.

Don't you ever run into cases where you have an argument with a 0 value which is inappropriate for the query ...?  The text example you gave seems like one of the few cases where the 0 value is likely to have intended semantics ...  It doesn't seem like there's a way to represent a query with an optional integer parameter at all?  And then for parameter types like integer[] -- being unable to distinguish the empty array from null also seems generally annoying/error prone to me ...  I think I'd rather conceptually make all arguments have pointer type and define my queries to either blowup or supply an appropriate default semantic for all nil parameters ...

Parsing: To do it properly would require a better parser. Simple things like pggen.arg('foo', 2) are easy enough. But it's not clear where to draw the line. Should pggen.arg support any scalar value? pggen.arg('foo', exists(SELECT 1 FROM ...)). Currently, pggen's "parser" only recognizes strings, semicolons, and comments--which is the minimum syntax needed to identify a complete query.

Maybe I'm wrong here ... but wouldn't it be correct to just keep count of the non-string-enclosed open/close parenthesis until we find the closing paren that represents the end of the ppgen.arg() expression ...?

Maybe I'm wrong here ... but wouldn't it be correct to just keep count of the non-string-enclosed open/close parenthesis after the ',' until we find the closing paren that represents the end of the ppgen.arg() expression ...? (and also disallow use of ppgen.arg( within the default value expression)

I put a sketch of this here -- https://github.com/breathe/pggen/commit/896a9d4d705ba51e927a1baf891b72e69e176678
Might an approach like this work in terms of additions needed in the scanner/parser ...?

Thanks for experimenting with the code! Adding a Directive is a good idea as I'd like to eventually support dynamic predicates: pggen.predicate.
It seems like the main problem is there's no way to pass null as an input with pggen.arg.
If pggen could pass null:

We get default values with plain SQL like coalesce(pggen.arg('foo'), 'some_text').
Your example of defining pggen.arg with a case statement would work since it could emit null, and the default value is handled by the coalesce, which lives in the query.

Let me know if that matches your understanding. If it does, I'd prefer to figure out how to pass null values via pggen.arg since it's a more general mechanism and avoids expanding the API surface. A few other feature requests also boil down to supporting more flexible marshaling for pggen.arg and unmarshaling for the returned column types, including:

https://github.com/jschaf/pggen/issues/65
https://github.com/jschaf/pggen/issues/46

I went ahead and wrote a PR to implement ... Let me know what you think?
Thanks!!

Closing as I gather there is not interest in supporting the interactive use case

authors: breathe jschaf

repo: jschaf/pggen


text:
🛑 API is down

In 32bca04, API ($SERVER_BASE/api/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: API is back up in bbdbacc after 19 minutes.

repo: jscmidt/upptime


text:
🛑 Grafana is down

In a237c20, Grafana ($SERVER_BASE/grafana/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Grafana is back up in 25071b3 after 10 minutes.


text:
New Rule: disallowIdenticalDestructuringNames

Fixes #1081
Closes gh-1844
cc @iamdanfox

Still WIP?

No tests are passing now so I think I'm good

If anyone can review first?

all good

Ok merging then

authors: hzoo markelog

repo: jscs-dev/node-jscs


text:
requireSpace(Before|After)BinaryOperators: Add tests for error column

Adds additional unit tests to verify the detected error's column value is correct for  requireSpace(Before|After)BinaryOperators, that is, it points to the beginning or end of the operator as appropriate.
Closes #756

Coverage remained the same when pulling 3ec56885fc86e1f96ecdb77b54c567435a33351a on hpshelton:requireSpaceBinaryOperatorsTests2 into 4c31d9ee8039d87aa6db346b5efe7d5679551d21 on jscs-dev:master.

No code changes only tests, i think i love you :-).
Before assertion API this job was on getPointerEntities method, but now it's used only once and with assertions API we no longer need it.
Would you like to remove this method and adapt requireOperatorBeforeLineBreak logic to the assertion API?

authors: coveralls hpshelton markelog


text:
[swc-angular-plugin] preserve styles for using this plugin for dev server

I have an Angular dev server using swc, this plugin solved the code transformation problem a lot.
However this plugin discards all styleUrls and replaces them with empty styles: [].
Can we have some options to preserve styles in the result, so we can use it for Angular dev server?

Thanks for raising this issue.
This was indeed a shortcut we took as we focused on speeding up "browserless" testing.
We should fix this.
All PRs are welcome! 😊

So I tried to add transforming styleUrls, it now works well on the dev server.
When running tests in this repo, Vitest is fine, but Jest reports error due to CSS imported as objects.
We need to either make preserving styles optional (enabled or disabled by default), or add a workaround
to the existing Jest configs (might make this a breaking change).
Which one is better?

repo: jscutlery/devkit


text:
Components fail to start in full CF environment

I'm looking to run this in a full CF deployment (not bosh lite) and am hitting issues getting some of the core components to start.
The stub apps and the dbserver all start correctly, but the usage-collector and usage-meter both fail consistently with the following log output:
2015-07-16T12:44:57.95+0000 [DEA/0]      OUT Starting app instance (index 1) with guid 041dad24-2043-473b-a923-4394839f7079
2015-07-16T12:45:00.04+0000 [App/1]      OUT Detected 1024 MB available memory, 512 MB limit per process (WEB_MEMORY)
2015-07-16T12:45:00.04+0000 [App/1]      OUT Recommending WEB_CONCURRENCY=2
2015-07-16T12:45:00.44+0000 [App/1]      OUT > cf-abacus-usage-meter@0.0.1 start /home/vcap/app
2015-07-16T12:45:00.44+0000 [App/1]      OUT > webapp start 9081
2015-07-16T12:45:52.67+0000 [App/1]      ERR
2015-07-16T12:45:52.70+0000 [DEA/0]      ERR Instance (index 1) failed to start accepting connections
2015-07-16T12:45:52.70+0000 [API/0]      OUT App instance exited with guid 041dad24-2043-473b-a923-4394839f7079 payload: {"cc_partition"=>"default", "droplet"=>"041dad24-2043-473b-a923-4394839f7079", "version"=>"646eedac-2d32-439d-bca3-73adb90f12d7", "instance"=>"ca18969f323e45c588d04847160af967", "index"=>1, "reason"=>"CRASHED", "exit_status"=>255, "exit_description"=>"failed to accept connections within health check timeout", "crash_timestamp"=>1437050752}
2015-07-16T12:45:52.71+0000 [API/0]      OUT App instance exited with guid 041dad24-2043-473b-a923-4394839f7079 payload: {"cc_partition"=>"default", "droplet"=>"041dad24-2043-473b-a923-4394839f7079", "version"=>"646eedac-2d32-439d-bca3-73adb90f12d7", "instance"=>"ca18969f323e45c588d04847160af967", "index"=>1, "reason"=>"CRASHED", "exit_status"=>255, "exit_description"=>"failed to accept connections within health check timeout", "crash_timestamp"=>1437050752}
2015-07-16T12:45:59.36+0000 [App/0]      ERR
2015-07-16T12:45:59.40+0000 [API/0]      OUT App instance exited with guid 041dad24-2043-473b-a923-4394839f7079 payload: {"cc_partition"=>"default", "droplet"=>"041dad24-2043-473b-a923-4394839f7079", "version"=>"646eedac-2d32-439d-bca3-73adb90f12d7", "instance"=>"310a8de5599e45ce8e96324197021190", "index"=>0, "reason"=>"CRASHED", "exit_status"=>255, "exit_description"=>"out of memory", "crash_timestamp"=>1437050759}

I suspect this is due to the apps not being able to talk to the cf-abacus-dbserver app (although I have no proof of this).
My CF runs behind a proxy, to deploy the apps I need to add http_proxy, https_proxy and no_proxy env vars to the manifests (as well as removing the buildpack line as my CF has nodejs support by default).
The apps stage, but fail to start.

It looks like the meter app is not even listening on its HTTP port.
You can get a more detailed log like this:
cf set-env cf-abacus-usage-meter DEBUG "*"
cf restage cf-abacus-usage-meter

Could you post the log output with that DEBUG *?

Actually, this line in the original log you posted just caught my eye:
OUT App instance exited with guid 041dad24-2043-473b-a923-4394839f7079 payload: {"cc_partition"=>"default", "droplet"=>"041dad24-2043-473b-a923-4394839f7079", "version"=>"646eedac-2d32-439d-bca3-73adb90f12d7", "instance"=>"310a8de5599e45ce8e96324197021190", "index"=>0, "reason"=>"CRASHED", "exit_status"=>255, "exit_description"=>"out of memory", "crash_timestamp"=>1437050759}

I just noticed now the "out of memory" at the end of the line.
These apps are not supposed to use so much memory, so I'm going to experiment too with several CF deployments I have and will post back here what I find.

If it helps, we are using the latest 1.4.2 buildpack for nodejs.

I found that some of the apps by default create one worker process per CPU (using Node.js cluster) on the machine they're on. That could be what's causing the apps to consume more memory in your environment.
While one worker per CPU may provide the best performance for heavy load in some environments, a default config usually shouldn't need that many workers. I ran into a similar out of memory error too when I tried the app in a high-CPU environment causing more workers to be created and consume more than the 512M configured for the app.
I changed the default number of workers to 2 in f760f44 and made it configurable too. Can you try that version and see if it solves your out of memory issue?

That commit solved the problem.
I failed to notice the out of memory message originally.

authors: johnmcteague jsdelfino

repo: jsdelfino/cf-abacus


text:
Buffered parsing: add parse() method, and return Tokens from take_while() and take()

This takes the [BufferedTokens] stuff from @Easyoakland's PR (#11) and makes a few tweaks with the following rationales:

Don't add a separate Buffer associated type for now, because I'm not sure how I feel about it:

When you need eg a &str buffer, is it better to use StrTokens directly (perhaps we could allow one to easily take slices of this given some locations? Does exposing the buffer type sortof go against the "iterator centric" style of this library.
If you do set the buffer type to eg &str, do you limit the possible Tokens impls that would work with that enough anyway that there's no point trying to be generic anyway now?

Buffered values return Result and not Option, because FromStr already has a variant for handling empty cases anyway, so we don't need separate handling (I tweaked a function to avoid this also).
Tweak StackString (I think I prefer that name to ArrayString; the differentiating point afterall is that it's on the stack) to limit it to taking chars only and having a push fn which accepts chars and not bytes. My goal here was to limit the ways that it can panic (now, only if it runs out of space it will panic, which seems reasonable).
Tweak some of the examples and tests.
Upgrade a couple of FnMuts to FnOnces because we only need to call them once.
Make the buffered functions not consume any tokens if parsing fails (this is consistent with how other functions work)

@Easyoakland what do you think?

I'm still feeling somewhat on the fence about this:

The functions that you can call in buffered() are (currently) all string related (unlike the core combinators of this library)
Some of them are just very tiny wrappers around parse_while anyway, so maybe they don't carry their weight
signed_digits is sortof useful but also stands somewhat on its own here; it's even more specific than the rest.

So a part of me is wondering about moving the parse_* methods onto the main Tokens trait, or perhaps putting them behind a parse() function instead of buffered() so that they are a little more discoverable and it's more obviously just "string parsing functions that happen to require a buffer". And then I would probably ditch the other methods for now (and maybe StackString too; it can panic quite easily and maybe it's best if that is user provided; nice that it's possible though!)

I went and renamed buffered to parse, and removed all but the 3 "core" methods (now named from_n, from_remaining and from_filtered). I think I'm feeling better about this for now!

I was still a bit unhappy that things didn't play quite as well together as I wanted, but I think I am now happy with this next reworking. Now:

Tokens::parse() is the single method for buffered parsing, to replace parse_n, parse_reamining and parse_while.
Tokens::tokens_while(..) is now Tokens::take_while, and the thing it returns impls Tokens too.
Tokens::take(n) has been added and also returns a thing which impls Tokens.

Together, we can get back the prev functionality:
// Equivalent to tokens.parse_n
tokens.take(3).parse::<u16, String>();

// Equivalent to tokens.parse_while
tokens.take_while(|t| t.is_alphabetic()).parse::<u8, String>();

// Equivalent to tokens.parse_remaining
tokens.parse::<Foo, String>();

I've kept buffer::StackString around for now, as much as anything as a nice example of how to make such a buffer.

Replying in order:

When you need eg a &str buffer, is it better to use StrTokens directly (perhaps we could allow one to easily take slices of this given some locations? Does exposing the buffer type sortof go against the "iterator centric" style of this library.

It is not strictly better. I made it this way is so yap_streaming could be used by swapping out the initial construction of the token. It would benefit there too as it already has to collect things into an internal buffer for backtracking, So you could still get minimal copies while parsing a source that didn't start in memory.

If you do set the buffer type to eg &str, do you limit the possible Tokens impls that would work with that enough anyway that there's no point trying to be generic anyway now?

See above

Buffered values return Result and not Option, because FromStr already has a variant for handling empty cases anyway, so we don't need separate handling (I tweaked a function to avoid this also).

Good point. That's better.

Tweak StackString (I think I prefer that name to ArrayString; the differentiating point afterall is that it's on the stack) to limit it to taking chars only and having a push fn which accepts chars and not bytes. My goal here was to limit the ways that it can panic (now, only if it runs out of space it will panic, which seems reasonable).

I changed it for two main reasons. First, it matches ArrayString. Second, its defining feature isn't really that it's on the stack. It's that it's inline (e.g. Box<StackString>)
I think it's reasonable to expect the library user to import the type they are interested in from another crate and only use StackString/ArrayString for testing (or just add a new dev-dependency). The only reason I can think of to keep it here is for convenience, but I question if it is actually more convenient.

And then I would probably ditch the other methods for now (and maybe StackString too...

It looks like you agree.

Make the buffered functions not consume any tokens if parsing fails (this is consistent with how other functions work)

I thought I did that. If I didn't it was an oversight. Regardless, that makes sense.

Some of them are just very tiny wrappers around parse_while anyway, so maybe they don't carry their weight

Agree.

signed_digits is sortof useful but also stands somewhat on its own here; it's even more specific than the rest.

Yeah, this method was basically the only reason I added them at all.

I was still a bit unhappy that things didn't play quite as well together as I wanted, but I think I am now happy with this next reworking. Now: ...

That was a good idea. I have to test it some to check, but that solution looks much nicer.

Maybe helper functions like signed_digit would be nice to have around, although I think perhaps that if I were to start adding such things, I'd add a helpers/utils module which just exposed a bunch of freestanding methods to do some common parsing tasks.

Agree. Totally makes sense to decide what, if any, to add later after the core methods are added.

The associated buffer method does allow less copying. I'd have to benchmark to see if it mattered. This proposed method is certainly elegant.
The other idea I'd have is to implement a parse_slice taking a start and end TokenLocation. The TakeWhile and related forward calls to parse as calls to the wrapped token implementation's parse_slice, but now StrTokens and StreamTokens and other implementations are free to implement a more efficient parse method knowing they have a buffer. Basically changing the doc on this new parse_slice and parse to be "may use the provided buffer type if extra buffering is needed". You'd get the advantage of no copies without much api change.
If this was a good idea parse_slice could come later since it should easily integrate with the current method.
@jsdw thoughts on this?

The main issue I see with the parse_slice addendum is that a Tokens without an existing buffer will wind up iterating twice (once to get the final position and once to collect up the elements). Which is probably worse than just always copying the elements and thus not worth the overhead of another method.

Thankyou for your detailed responses!
I liked your parse_slice() idea, and like that we can then make parse() (and itself) avoid allocating with StrTokens (and hopefully the yap_streaming version) without adding an associated type Buffer at all, so I've pushed a commit which does that and am curious to see what you think!
This ticks off the main place I'd want to avoid allocations personally; the case where you use yap to parse some stringish tokens, but then need to go and call some external parsing function to turn that string into the desired type (eg a number).
I'm still open to thinking about adding a type Buffer, but now that we can tokens.parse() without allocating for suitable token types, I have a lot of what I'd want :)

I think it's reasonable to expect the library user to import the type they are interested in from another crate and only use StackString/ArrayString for testing (or just add a new dev-dependency). The only reason I can think of to keep it here is for convenience, but I question if it is actually more convenient.

Ok, yeah I have been quite on the fence about keeping it around anyway, so I'll just ditch it and leave it to the user to bring their own buffer!

Aside from fixing a couple of bits, I hid parse_slice from the docs (use slice(from,to).parse() instead), and made Take and TakeWhile both make use of it too, so things like StrTokens can be optimal in all of the main cases.

The main issue I see with the parse_slice addendum is that a Tokens without an existing buffer will wind up iterating twice (once to get the final position and once to collect up the elements).

The way it's implemented at the moment, doing take_while().parse() or whatever will do one iteration through the tokens to find out which tokens need parsing and then:

In the default case, go back through (albeit without any need for any more checks) again to collect them up in the Buffer, or
In the StrTokens optimised impls, we won't need to iterate over them to collect them and can just directly parse the str slice.

Yeah, that's what I was describing.
For accessing the buffer directly, I think if I still found it necessary I could impl a new trait on the tokens so it doesn't need to happen here.
You might want to add a benchmark (criterion) comparing .as_iter().collect::<String>().parse() vs .parse::<_, String>(). And another comparing how that double iteration affects IterTokens and StrTokens.
Hopefully the result of that will be positive. If so I think this was a overall good addition!

Aah, at the time it didn't quite click that having all of the parse functions iterate once to find the start and end location, and then likely again in the default parse_slice impl was not optimal. In order to be (I think) as optimal as possible, I've now added parse_take_while and parse_take. Now, each of Slice, Take and  TakeWhile delegates parse() to the corresponding function on Tokens, which avoids needing to iterate over tokens twice.
With this, I do agree that benchmarks would be nice to add anyway, but I won't add them here (probably an issue would be good) since I think nothing wasteful is happening now.
Good point about being able to define a trait which mentions a buffer type, if it's useful to be able to access it for other reasons :)
If there are no objections I'll probably merge this in the next day or so and put a release out! (I'm also running out of time I want to dedicate to this for now, too; too many other things to do!)

Doing toks.take(n).take_while(f).parse() can be take_while(cursor <n && f). Same with toks.take_while(f).take(n).parse()`
You forgot adding parse... methods to Context, ContextMut.
While you updated the crate example, the json.rs and README examples could also be updated to use this instead of the old .as_iter().collect().parse()

Brill, thanks for spotting these; I added all of the obvious nested parse optimisations inc the ones you suggested (there are more that could be added but they aren't definitely optimal any more), and addressed your other points!

Is there a reason that tok.slice(from, to).take(n) and tok.slice(from, to).take_while(f) can't benefit from the same?

Is there a reason that tok.slice(from, to).take(n) and tok.slice(from, to).take_while(f) can't benefit from the same?

I'll have a look later; it was quite late when I did the above and partly I just didn't want to think about it!

I'm inclined to leave that for separate PRs

Sure.

I think the token.consume() you added, to use your terminology, is a low-value method. You can use token.as_iter().for_each(drop).

I think the token.consume() you added, to use your terminology, is a low-value method. You can use token.as_iter().for_each(drop).

Maybe, but i had used that several times already In different places :)

I wouldn't keep consume, but other than that I have no comments.

See https://github.com/rust-lang/rust/issues/64117 for discussion.

See https://github.com/rust-lang/rust/issues/64117 for discussion.

Thanks for the link! It's a little more useful of an alias here because of the additional .as_iter() bit, and it's simple + very generically useful, so I think I'll keep it. I also added collect() to sit next to it as an alias for collecting (and sortof complement for parsing), because that is super common, and It'd be nice if you didn't need to reach for .as_iter() methods much in normal usage.
Slice, TakeWhile and Take I'd already made impl Tokens instead of Iterator. I also standardised that now all of the other structs returned impl Tokens instead of Iterator which I think makes sense overall (if just to be consistent).

@Easyoakland re Tokens::eof and Tokens::line_ending:

Is there a reason for eof to care about consuming the None if found? (otherwise, tokens.peek().is_none() would apply.
I'm tempted to remove/move line_ending because it's Tokens<Item=char> specific; it's a good candidate as a standalone utility method for working with char tokens.

Is there a reason for eof to care about consuming the None if found? (otherwise, tokens.peek().is_none() would apply. It feels a bit of a niche thing to want to happen (consuming on None vs not).

If the iterator is fused it doesn't matter. If the iterator is not fused (e.g. Some(1) None Some(2)) then it makes sense to consume the None the same way tok.tokens consumes instead of just returning a bool.

I'm tempted to remove/move line_ending because it's Tokens<Item=char> specific; it's a good candidate as a standalone utility method for working with char tokens.

Sure. Put it where you want (new crate, new module, etc). Maybe this is how you start filling a character module leaving room for bytes and bits modules which apply to Tokens<Item = u8>/Tokens<Item = bool>? You could leave adding new functions to the future. (signed_digits would also go there if decided to re-add).

If the iterator is fused it doesn't matter. If the iterator is not fused (e.g. Some(1) None Some(2)) then it makes sense to consume the None the same way tok.tokens() consumes instead of just returning a bool. Delete eof if you want.

I'll just leave it as-is; it's only a small thing, and if people don't want to consume then toks.peek().is_none() is there, and so this is a bit like calling toks.token(EOF) conceptually.

Sure. Put it where you want (new crate, new module, etc). Maybe this is how you start filling a character module leaving room for bytes and bits modules which apply to Tokens<Item = u8>/Tokens<Item = bool>? You could leave adding new functions to the future. (signed_digits would also go there if decided to re-add).

I moved it to a new chars module, because yup, I think we could add some other helper things there eventually (one that comes to mind is a proper IEEE float parser).

Two more things that can come after merging this increasingly large PR

Instead of manually defining token wrappers you could make a macro. In the macro you could remember to forward to the parse... functions, which I think you forgot again and probably will in the future as well.
If tokens is going to have a into_iterator method it may as well be IntoIterator and defined for both &mut Tokens and Tokens.

If tokens is going to have a into_iterator method it may as well be IntoIterator and defined for both &mut Tokens and Tokens.

Do you mean, making trait Tokens: IntoIterator?

Instead of manually defining token wrappers you could make a macro. In the macro you could remember to forward to the parse... functions, which I think you forgot again and probably will in the future as well.

Heh, yeah potentially!

And yup, probably time to merge this; it's turned into a general "work on yap for a bit" PR!

Do you mean, making trait Tokens: IntoIterator?

That or <T: Tokens> IntoIterator<T> with type = TokensIntoIter

Ooh, alas Rust wouldn't allow such a blanket IntoIterator impl otherwise I'd love to have that. I'm much less keen on Tokens: IntoIterator because it just adds a hurdle to implementing the trait that's a bit of a nuisance.

Anyway, thankyou for all of your time and comments on this; they are much appreciated! I think this parse stuff has worked out quite well in the end, and it's lovely to be able to avoid the "allocate intermediate buffer" in the common cases.

your collect docs appear messed up.

your collect docs appear messed up.

Argh, it'll be this laptop touch pad; I do that far too often... Fixed on master :)

authors: Easyoakland jsdw

repo: jsdw/yap


text:
/proc/fbX not created

I can't forward image because of not created /proc/fbX
# ./vcam-util -l
Available virtual V4L2 compatible devices:
1. vcamfb0(640,480,rgb24) -> /dev/video0
2. vcamfb1(640,480,rgb24) -> /dev/video1
3. vcamfb2(640,480,rgb24) -> /dev/video2

# ls -al /proc/fb*
-r--r--r-- 1 root root 0 Jul  4 06:01 /proc/fb

will create vcamfbx in /proc/

will create vcamfbx in /proc/

@WayneLin1992, can you provide the documentation fix?

Close via commit 3fe27eb9b1bf448ade667e310760f98eb8f20ed7

repo: jserv/vcam


text:
--exclude-path doesn't behave correctly with absolute paths

Here are steps to duplicate the problem:
cat <<EOF > ignorefile
*.js
**/*.js
EOF
echo "not really javascript" >> foo.js

This works as expected:
jshint --exclude-path ignorefile .

This doesn't:
jshint --exclude-path ignorefile $(pwd)

producing
/tmp/bar/foo.js: line 1, col 1, Expected an assignment or function call and instead saw an expression.
/tmp/bar/foo.js: line 1, col 4, Missing semicolon.
/tmp/bar/foo.js: line 1, col 5, Expected an assignment or function call and instead saw an expression.
/tmp/bar/foo.js: line 1, col 11, Missing semicolon.
/tmp/bar/foo.js: line 1, col 12, Expected an assignment or function call and instead saw an expression.
/tmp/bar/foo.js: line 1, col 22, Missing semicolon.

6 errors

I know this is old but I still see it happening. It makes jshint ignore quite confusing.
Can we get this fixed?

authors: iffy jodonnell-broadsoft

repo: jshint/jshint


text:
Show a warning on ambiguous returns

Thanks to @goatslacker and GH-328, we can now parse statements like return x = 2;. That said, this code is ambiguous so we should show a (default) warning when stumbling upon such usage.

I have a fix for this here: 8b18a0e4a91fc842d9efdfcb8aaea0abd0e00d3d but I feel uneasy about it. Mainly because I don't feel this should be a warning at all, even then there should be a way to turn this off. Any thoughts to what we'd call that option?

authors: antonkovalyov goatslacker


text:
Make arguments not a reserved keyword.

This patch changes the handling of arguments so that it is not considered a
reserved keyword. It is not listed as a reserved keyword on either MDN or the
ES5.1 specification: http://www.ecma-international.org/ecma-262/5.1/#sec-7.6.1
I verified that the following code works in IE 8, Chrome 32, and Firefox 26.
function arguments() {
  return arguments[0] + arguments[1];
}
var object = {};
object.arguments = arguments(1, 2);
object.arguments === 3;

Hello,
Maybe the warning should change at least, currently I see:
Expected an identifier and instead saw 'arguments' ( a reserved word).

when I use arguments as a parameter but arguments is not a keyword.
Perhaps something like "Warning value of arguments replaced by function parameter" ?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#Keywords

authors: metasansana yungsters


text:
Version 2.14.0

This is a tracking branch for the next minor release of JSHint. If you'd like to implement a new feature, this is the place to submit it!
ES2021 features:

[ ] WeakRefs
[ ] Logical assignment
[ ] Numeric separators

Coverage decreased (-0.02%) to 99.98% when pulling fcadc12f37e26a3cffcb0cd16758f05ed5eb0351 on v2.14.0 into 057b1c6e8e17b8d9e1ddb8254bb44b4bc5ece710 on main.

authors: coveralls jugglinmike


text:
JSON:API Object in requests?

The specification (both 1.0 and draft 1.1) describe cases where the server might want to return a "jsonapi" top-level member, but there is nothing about how a server should handle such a member found in a request.
Should a client include a JSON:API Object with a request to indicate what specification version(s) it supports?

As a server implementer, I think I would be happy if more clients implemented it. The advantage is that I'd have some insight into the capabilities of its clients and could perhaps upgrade/deprecated things sooner/later with that information. That said, the spec itself is perfectly okay with clients and server omitting it. It's purely an available enhancement.

authors: freddrake gabesullice

repo: json-api/json-api


text:
Propose to use orjson as the preferred backend

simplejson is used by jsonpickle as a fast backend for JSON encoding. This was true back when jsonpickle was created, but as of now, there are multiple Python JSON libs that are way faster than simplejson. Among which, orjson is fastest.
Benchmark: https://github.com/ijl/orjson#performance
Its fast performance is backed by several other benchmarks, including one done by its competitor ujson:

https://github.com/ultrajson/ultrajson#benchmarks
https://pythonspeed.com/articles/faster-json-library/

So I propose to replace simplejson with orjson as the preferred backend, or we can keep simplejson and just add orjson.
If any of the approaches makes sense to you, I'm happy to make a PR. Please let me know what you think.

Never mind, orjson is not compatible with stdlib json.

repo: jsonpickle/jsonpickle


text:
Exercise_05_23 is wrong!

There should be two different sums, if not the the final sum will be added to the first sum and thus wrong output.

Thanks will try and correct.

Looks like you fixed it. Go ahead & close the issue

Wow, that was fast, thanks a lot man. :)

authors: SleekPanther SquirrelCoder jsquared21


text:
Cache filtering by font

Filtering by font occurs frequently, and involves checking the font of each element.
It could be worth caching the filtered elements for each font somewhere on the document. This shouldn't be done at load, only when the function for each font is called.

This should probably be done in all of the filtering functions that operate of immutable properties (i.e., fonts, text, pages).
Also, maybe using https://docs.python.org/3/library/functools.html#functools.lru_cache would be a good idea.

@pauloAmaral Hmm, the problem with e.g. caching by text is that there are so many possible inputs. The reason I was thinking about fonts was that there is a very limited set of fonts for each document.
I don't think it'd be as simple as using lru_cache because you can filter_by_font on any element list, and depending on the elements within the list it will return something different. You'd end up with a different cache for each element list, which feels a bit pointless?
I was thinking of having an _elements_by_font: Dict[str, set[int]] on the document (mapping fonts to set of element indexes), and then the filter_by_font on the element list would just do self.indexes & document._elements_by_font[font] to get the new indexes.
I think the set operation should be quite quick. Obviously it does mean that in some cases you'd be considering all the elements in the document even when your element list is tiny, but I do this it's probably a lot quicker than checking all the elements manually in each case.
What do you think? Perhaps I'm overcomplicating it somehow, but I don't see how it would really work for text etc. How do you envisage it working for e.g. text? Additionally, I think it doesn't make sense for pages since that should already be pretty efficient because we just lookup the page and get the start and end index.

I think I agree with both your points:

There are potentially too many inputs for text so doesn't make sense, and looking at the code fetching by pages is fast enough so no need for cache.
I admit I didn't consider that we would end up with too many caches... Having an _elements_by_font seems to be the right answer for this case.

authors: jstockwin pauloAmaral

repo: jstockwin/py-pdf-parser


text:
Feature Issue Template

Description:
As this is a new repository, we need Feature Issue Template for new feature tickets alone. The template should have below mentioned input fields
Feature Issue template Requirement:

Feature title should start with - [FEATURE]
Description of the FEATURE
Motivation for this new feature
Frontend/ backend issue
Screenshot of the feature if done
Are you taking this feature implementation

The template should be under .github/ISSUE_TEMPLATE/REQUEST-REPO-FEATURE-REQUEST.yml
Reference: https://github.com/stevemao/github-issue-templates
PR Requirement:

Please check the above requirements are met
Always create new branch on forked repo from master to avoid and error while merging the fix
Please Star this repo while forking as that would increase this repo's visibility

Cheers 🎉

HI @jsvigneshkanna can you assign this issue to me

@AmanPachori , you can start working on this feature

authors: AmanPachori jsvigneshkanna


text:
Source maps empty when using UglifyJsPlugin

My sass source maps are generated with no mapping data when I enable the UglifyJsPlugin:
{"version":3,"sources":[],"names":[],"mappings":"","sourceRoot":"","file":"styles.css"}

When I remove the plugin, source maps work as expected.
Here is my config file (with the plugin enabled):
var webpack = require('webpack');

var bourbon = require('node-bourbon').includePaths;
var neat = require('node-neat').includePaths;

var extractTextPlugin = require('extract-text-webpack-plugin');
var commonsPlugin = new webpack.optimize.CommonsChunkPlugin('common.js');
var uglifyPlugin = new webpack.optimize.UglifyJsPlugin({
    compress: {
        warnings: false
    }
});

module.exports = {
    entry: {
        onboarding: './onboarding/index.js',
    },
    output: {
        path: '../public/webpack',
        filename: '[name].js' // Template based on keys in entry above
    },
    plugins: [commonsPlugin, uglifyPlugin, new extractTextPlugin('styles.css')],
    devtool: 'source-map',
    module: {
        loaders: [
            {
                test: /\.scss$/,
                loader: extractTextPlugin.extract(
                    'css?sourceMap!' +
                    'sass?sourceMap&includePaths[]=' + bourbon + '&includePaths[]=' + neat[0] + '&includePaths[]=' + neat[1]
                )
            },
            {
                test: /\.(png|jpg)$/,
                loader: 'url?limit=8192'
            },
            {
                test: /\.woff(2)?(\?v=[0-9]\.[0-9]\.[0-9])?$/,
                loader: 'url?limit=8192&minetype=application/font-woff'
            },
            {
                test: /\.(ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
                loader: 'file'
            }
        ]
    }
};

Thx, I'll take a look

I'm not sure if this is a bug in webpack (UglifyJsPlugin), or sass-loader, or css-loader. But I was having the same problem, and was able to fix it by adding &-minimize to my css-loader config:
{
    test: /\.scss$/,
    loader: extractTextPlugin.extract(
        'css?sourceMap&-minimize!' +
        'sass?sourceMap&includePaths[]=' + bourbon + '&includePaths[]=' + neat[0] + '&includePaths[]=' + neat[1]
    )
},

@jgerigmeyer Thank you. Was pulling my hair out trying to figure this out.

Is this still an issue?

Just tested with v2.0.0, and it seems to be fixed. Thanks!

I'm glad to hear that :+1:

PS - this looks like it is an ExtractTextPlugin issue. https://github.com/webpack/extract-text-webpack-plugin/issues/119

authors: chrisguerrero elsigh jgerigmeyer jhnns mking

repo: jtangelder/sass-loader


text:
[Question] Do you recommend any "differential methylation" methods that use output from nanopolish?

I currently have quite a bit of frequency tables generated from nanopolish.  I have 2 conditions for my experiments and was wondering if there are any differential methylation scripts available in nanopolish or if you recommend any methods that can make use of this data?
In particular, the output from calculate_methylation_frequency.py.
My apologies if this is out of scope.  If so, I will close the issue immediately.

Hi @jolespin,
We don't have an officially recommended differential methylation approach yet. You might look at https://github.com/a-slide/pycoMeth and https://github.com/wdecoster/methplotlib for ideas on how to compare across samples.
Jared

Thanks a lot @jts !  These look really intuitive to use.  Looks like my only hurdle is a good way to merge replicate runs of calculate_methylation_frequency.py that I should have merged before running nanopolish in the first place so I can properly use pycoMeth.  I have some ideas for this though.  Cheers

authors: jolespin jts

repo: jts/nanopolish


text:
used future print_function to improve py2-3 compatibility

Hi there, noticed that the python scripts were a mix of python 2 and 3, mostly due to print statements, and this led to some issues for me (in particular, 0.9.0 requires python 2.7 on bioconda, and I primarily work in 3.6).
So I added from __future__ import print_statement to the relevant files. I believe that this should make the python scripts 2/3 compatible. Let me know if there are any problems.

Thanks for the PR!

authors: jamestwebber jts


text:
⚠ Agora Aveiro has degraded performance

In c14227e, Agora Aveiro (https://agoraaveiro.org) experienced degraded performance:

HTTP code: 200
Response time: 6419 ms

Resolved: Agora Aveiro performance has improved in 28671be after 10 minutes.

repo: jtsimoes/upptime


text:
Apis publicas

Nacionales

API CMF Bancos .v3

API CMF Bancos .v3

authors: githubcristian romicofre romiyapp


text:
API Reveniu: Métodos de pago

Reveniu: API REST para modelar el flujo de cobro y gestión de suscripciones de tu negocio dentro de tu aplicación en formato whitelabel.

added 64b90576e478f75d76e5f2c8d5576e7e176867bc

authors: juanbrujo miguelpaz


text:
main.py run multiprocess fixed

python main.py microphone/path_to_wav all met the error
RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
        in the main module:

            if __name__ == '__main__':
                freeze_support()
                ...

        The "freeze_support()" line can be omitted if the program
        is not going to be frozen to produce an executable.

So we add to make it run successfully.

I just released pyannote.metrics 3.1 that (I think) was causing this issue.
Can you please confirm that upgrading to pyannote.metrics 3.1 solves this issue?
pip install pyannote.metrics==3.1

I'm closing this because of inactivity, feel free to reopen if needed

authors: hbredin juanmc2005 songtaoshi


text:
Fix negate of list objects

When trying to use the is_negate field it will also negate list objects that arent supposed to be negated. This is due to the fact that we were setting is_negated even if the key wasnt in the json_mask. This PR is to fix this by only accepting is_negated field if the key is in the mask.
Testing

@joe-ipp Version 0.4.5 is available including your contribution.

authors: joe-ipp juanyque


text:
Replace "Preferred Infrastructure" with "Preferred Networks."

https://github.com/jubatus/jubatus/issues/906

Thanks!

authors: gwtnb kumagi

repo: jubatus/jubatus-mpio


text:
Warning in module foreach loop getting requirementsLabels setting for passwords

TracyDebugger reports a warning when opening module configuration admin page:
PHP Warning: foreach() argument must be of type array|object, null given in .../site/modules/FrontendForms/FrontendForms.module:2017

Line 2017 in the FrontendForms.module file of the current version is a comment and not a foreach loop ?!?
 // DISTORTION LINES
Please press the "Refresh" button for the modules to clear the modules cache and check if the warning is gone.

authors: donatasben juergenweb

repo: juergenweb/FrontendForms


text:
SwaggerUI is not working in Docker, but works locally. Only the SwaggerUI throws a 404 Not Found

Okay, I know this sounds weird ... but: The SwaggerUI is not working inside of Docker. ^^"
Let me explain what I did. When I write down everything like in the example for axum and I start the application with cargo run, I can see the swagger-ui and also see the /docs/openapi.json file.
Now the interesting part, when I compile the code inside docker and provide it inside docker only the swagger-ui endpoint (/docs in this example) is returning a 404 Not Found. But the interesting thing is, all other endpoints are working... Including the /docs/opanapi.json endpoint.
So, only the swagger-ui isn't working inside Docker. ^^"
I thought "maybe it's a compiled problem", so I copied the locally build binary (which worked on the machine and showed the swagger-ui) into the docker container, started it and "boom", no swagger-ui. ^^"
It's so weird that every endpoint is working, also the openapi.json endpoint (which shows the full generated openapi json), but only the swagger-ui HTML-Page is not working. There is really no difference inside the Docker container and my local machine (like I said, I copied the binary to prove my assumption).
I also tried bigger OS containers like ubuntu and smaller ones like alpine, in all containers every endpoint is working, except the swagger-ui. :(
Does someone have an idea what I could test/think of? I'm getting out of ideas. ^^"

I've created a small documentation change to pinpoint it better in the README. Maybe it will help out. :3

Maybe it makes sense that we pinpoint that "issue" out in the Readme, thank you very much! <3

Yeah, actually there is slight hint towards this in utoipa-swagger-ui README.md but it is not obivous to the eye.

Yeah, actually there is slight hint towards this in utoipa-swagger-ui README.md but it is not obivous to the eye.

Ah yeah, now I see what you mean. It wasn't quite obvious to me and two other people. So spending hours investigating that issue could be solved by pinpointing it out. :)

Ah yeah, now I see what you mean. It wasn't quite obvious to me and two other people. So spending hours investigating that issue could be solved by pinpointing it out. :)

True :slightly_smiling_face:

Relates to #268

authors: juhaku kerkmann

repo: juhaku/utoipa


text:
[Feat] 所有libra/transaction/support项目用到的组件以及他们的基础使用方式

PR 类型：

[x] 新功能 Feat
[x] 缺陷修复 Bug
[x] 文档改进 Doc
[ ] 重构和项目优化 Refactor or Perfs
[ ] 添加测试用例 Test

❗ 请务必确保：

[x] 代码经历过不少于 1 遍书写-构建-使用的自测流程
[x] 有全面的组件文档
[ ] TS 类型定义完整且没有恶意 any

⚠ 请尽量保证：

[ ] 有完善的组件测试，覆盖率不低于 85%

命名错误

repo: juicecube/mlz-admin


text:
showvalue not defined in Logging in Julia 1.11

Sometimes in my doc builds, it get the following error
ERROR: LoadError: UndefVarError: `showvalue` not defined in `Logging`

And indeed Logging.showvalue is called in this function
https://github.com/julia-actions/GitHubActions.jl/blob/e988cc204e34bf1b12b28c3f1f00e5ae347af30f/src/GitHubActions.jl#L259C1-L259C46
but does not appear to be defined in Julia 1.11

Same here: https://github.com/sintefmath/JutulDarcy.jl/actions/runs/11243998227/job/31274362490?pr=68

Same problem
https://github.com/rafaqz/DimensionalData.jl/actions/runs/11269812123/job/31339182058?pr=818#step:6:97

See #37

authors: Pangoraw hexaeder moyner rafaqz


text:
patch worked until chrome

First, thank you for your great job and the fix.
After some weeks the patched seemed to work, yesterday I restarted my MacBook.
I got Kernel-Panic. I run the patch again. ok. But since then I always get Kernel-Panic when I use Chrome especially Chrome and Mission-Control. 95% leads to instant panic.
So I tried to run the patch again and now I always get this not found error:
 | Checking compatibility
 MBPModelVersion :  MacBookPro6,2 ➔ Compatibility : OK ✓
  | macOS version :
 macOS 10.12
  | Checking SIP Status
 SIP Disabled
  | Searching for AppleGraphicsPowerManagement.kext
 AppleGraphicsPowerManagement.kext not found

and a file-selection dialog. But the AppleGraphicsPowerManagement.kext is there but can't be selected. In it's Content Folder there is also a Info.plist.
Following some other forums I moved the GeForce*.kext files to DisabledExtensions. Most things seem to work fine. But the Login Screen is very very slow after login. It refreshes the screen several times. Also using chrome feels like you would do it on 4x86 from 1994. Several screen part refreshing no input reactions.
What can I do now?

@FuscaSoftware Any updates ?

@FuscaSoftware If i get no update, I'll close the issue. Thanks

authors: FuscaSoftware julian-poidevin


text:
feat: Add picklist mode sample to the example app

This PR adds a picklist mode sample to the sample app.
This sample is not fully optimised, because of this issue:
MobileScannerState.size is not equal to BarcodeCapture.size on iOS

Can I do a demo in this form

Can you provide a demo like this ？

The latest version of the picklist sample uses the fact that the image size is now always available, also when returnImage is false. It still relies on two workarounds 'fixPortraitLandscape' and 'fixCorners'.
https://github.com/user-attachments/assets/0f1fc2e8-7f3c-4f41-b7c7-2bb45bd46229

authors: jsroest maxfrees


text:
Check type of dot syntax

In 3.x, we added several convenient aliases for standard optic composition, e.g.
case class Person(name: String, emails: List[String])
val emails: Lens[Person, List[Email]] = ...

emails.at(2)       // equivalent to emails.composeLens(at(2))
emails.index(2) // equivalent to emails.composeLens(index(2))

Since optics extend one another in 3.x, we have used overloaded methods to define at, index, etc ... Now, the problem is that it is easy to use the wrong type in those aliases. For example, Lens doesn't have an index method because the inherited method from Optional is correct. However, Lens overloads at method because the return type should be more precise (Lens composed with Lens gives another Lens).
Shall we add some tests for each alias to check? e.g.
for all optics o, for all alias a,
o.$a.type == o.compose(a).type

fixed in #789 for the 2 dot-syntax methods

repo: julien-truffaut/Monocle