text:
Get our domain pointed to the server

and get SSL working

Domain is live. Using a self-signed cert for now.

Got proper HTTPS working.

source: gharchive/issue

repo: moorepants/resonance

license: MIT

license_type: permissive

license_source: github-api


text:
SAR Transmitter Party Identification max occurence

FinCEN Version: 0.2.6
What were you trying to do?
We were trying to use the moov library to generate a SAR report and filling out the transmitter section.  The samples (from our bank) /XML user guide we got off of fincen indicates that there's two party identification under the Transmitter Party with code 35 but the moov library validation for this section says len(r.PartyIdentity) > 1 will throw an error
What did you expect to see?
We expected this party section to be validated properly with two party identification types
What did you see?
We got a validation error saying that partyidentity length > 1 (ie min/max range failed) in the fieldInclusion method
How can we reproduce the problem?
Try to make an Activity with a Party for transmitter code 35 and add two party identity.
Here is the lines of code that's failing in suspicious_activity/activity.go
case "35":
if len(r.PartyName) != 1 || len(r.Address) != 1 || len(r.PhoneNumber) != 1 || len(r.PartyIdentification) != 1 {
return fincen.NewErrValueInvalid("Party")
}

@mimy2001
Thanks for report

minOccurs and maxOccurs of party identification is one if party type is "35"
The element can exist several times if party type is "30"

Let me tried to find the other section, so this is what it says in one section, but there's another part of the guide which contradicts this.

Take a look at this, this clearly shows two party identifications within party type 35 as a Transmitter Party Record Example

And this section here, it says there is a TCC and TIN required for the transmitter party identification.

Btw, just another question, how do we generate the xml file with the fc2 prefix? All the moov library XML files I have do not have fc2 in front.

changed the validation logic with following spec

Btw, just another question, how do we generate the xml file with the fc2 prefix? All the moov library XML files I have do not have fc2 in front. @mfdeveloper508 sorry, just highlighting this question again.  and thank you for being so prompt in fixing this bug.

Actually maybe I should open up a different issue.  I'll close this one thanks

@mfdeveloper508 thanks! I have another couple of issues lol and I'll slowly raise them all. I created another issue for the namespace prefix.

repo: moov-io/fincen


text:
duplicate scheduling when running on multiple host

This gem works fine under general use case. However, we have some jobs that take longer time (20-25 min) and increases the queue latency.
During such scenario, jobs are scheduled twice which causes other issues in the app. There is a section in the readme that warns about this but is there a way i can minimize duplication? like tweaking certain parameters or limiting certain things?
OR can this issue be fixed in the gem itself?
Current config:

4 hosts
4 processes (1 per host)
12 threads each process
5 queue
6 recurring jobs using cron at different times.
There can be >100 jobs scheduled in a queue at the same time.

@rvyas you might want to take a look at sidekiq-uniq

Thanks @bpo. I will try this gem.
I was trying to do the same in the worker/checking other jobs in queue, etc, but there is some delay when those jobs show up in sidekiq APIs.

@rvyas I don't use that one myself, but I know others have had similar issues. Sidekiq Enterprise has built-in support for unique jobs, which would probably be your best choice if that's an option for you.

No, it did not solve the problem. Even with sidekiq-uniq I see the same duplicate scheduling although the rate has reduced.
May be I need to leverage built-in support.

@ryvas Were you able to solve your issue with sidekiq-cron?

@rvyas @mgoggin I didn't take a look at this gem https://github.com/mhenrixon/sidekiq-unique-jobs, but maybe it can help.

ok I think one solution for those problems will be to use a Redis based Lock instead of rufus-scheduler default filelock
https://github.com/jmettraux/rufus-scheduler#advanced-lock-schemes
This would allow us to use something like https://github.com/kenn/redis-mutex to create a single lock to all schedulers running on different hosts which would ensure that only one scheduler would be able to schedule a job at a given time.
I'll investigate more and make some tests, this may land as an experimental feature in v4.1

@marcelolx this seems like a tricky thing for sidekiq-scheduler to handle well, as it's still always possible for the app to enqueue jobs externally from the scheduler.

@bpo Could you exemplify?

I think there may be 3 issues here:
A) Sidekiq-scheduler can enqueue a job when it's already running
B) Sidekiq can enqueue a job when it's already running
C) Sidekiq can start running a job when it's already started
The initial description of the issue here is all 3 of those: The overall system has performance problems because two copies of a job are running at once (C), caused by Sidekiq enqueuing two copies of a job (B), and sidekiq-scheduler handled the actual enqueueing (A).
A is clearly a subset of B, which makes me think that a more general plugin to Sidekiq might be the right way to solve the whole problem rather than adding the complexity within sidekiq-scheduler.

Only thing we want is to avoid sidekiq-scheduler enqueueing duplicated jobs on multiple hosts

I think this means you are saying "we only want to solve A". I think you're right that A is solvable within sidekiq-scheduler. I wanted to raise a caution about added complexity vs value (since B/C will remain unaddressed) but it sounds like you've already thought that through.

got it @bpo, that makes sense! I agree that adding too much complexity is not a path we want to follow and yeah, what I am looking for is to solve A, just to avoid sidekiq-scheduler enqueue the same job when running on multiple hosts.

I would like to share one of our solution to this problem, (we ended up with different solution because we have a lot of dynamically scheduled tasks)
class RedisLock
  include Singleton
  attr_reader :redis

  LOCK_NAME = "rufus:trigger"
  INSTANCE_IDENTIFIER =  Socket.gethostname || SecureRandom.hex(10)

  def lock
      acquired =
        Sidekiq.redis do |r|
          res = r.set(LOCK_NAME, INSTANCE_IDENTIFIER, nx: true, ex: 5.minutes.to_i)

          res == false ? r.get(LOCK_NAME) == INSTANCE_IDENTIFIER : res
        end

      acquired
    end
  end

  def unlock
    true
  end

  def remove_instance_from_queue
    removed = Sidekiq.redis { |r| r.del(LOCK_NAME) }
    Honeycomb.add_field("scheduler_removed", removed == 1)
  end
end

# Monkey patched Sidekiq::Scheduler since we don't have way to
# inject scheduler_lock
module SidekiqScheduler
  class Scheduler
    def initialize(options = {})
      self.enabled = options[:enabled]
      self.dynamic = options[:dynamic]
      self.dynamic_every = options[:dynamic_every]
      self.listened_queues_only = options[:listened_queues_only]
      self.rufus_scheduler_options = options[:rufus_scheduler_options] || {}

      self.rufus_scheduler_options =
        rufus_scheduler_options.merge({ scheduler_lock: RedisLock.instance })
    end
end

This will make sure only one host can schedule. Each host needs to create a thread to check if rufus:trigger  is still set in redis and if not they can declare themselves as scheduler host if others haven't done that yet. Hope this helps.

@eldemcan You don't have to patch sidekiq-scheduler, it is just a matter of passing the scheduler_lock to the rufus_scheduler_options, no?
One question, what your team wants is a single scheduler running, right?
BTW, what happens if your server crashes and remove_instance_from_queue is not called to remove the lock? In the next deployment no server will be able to set up the scheduler, right?
Also, I suggest looking at how Square https://github.com/square/sqeduler have implemented its locking strategy using Redis which may be helpful (My plans are introduce support for that at some point, that you can opt-in, but first we want to solve https://github.com/sidekiq-scheduler/sidekiq-scheduler/pull/396)

@eldemcan You don't have to patch sidekiq-scheduler, it is just a matter of passing the scheduler_lock to the rufus_scheduler_options, no?

How can I pass options to rufus_scheduler instance inside  SidekiqScheduler:Scheduler?   SidekiqScheduler:Scheduler seems to be getting its options from yaml. Let me know if I am overlooking something

One question, what your team wants is a single scheduler running, right?

We want one instance to be able to schedule at a time but if that instance goes away another instance should be able to take that role.

BTW, what happens if your server crashes and remove_instance_from_queue is not called to remove the lock? In the next deployment no server will be able to set up the scheduler, right?

Key will expire in 5 min. (this could be shorter) So if remove_instance_from_queue is not called redis will remove the key. We could also create a thread that just keeps checking if key is set if not instance will set the key meaning they will declare themselves as scheduler amongs other hosts.

Also, I suggest looking at how Square https://github.com/square/sqeduler have implemented its locking strategy using Redis which may be helpful (My plans are introduce support for that at some point, that you can opt-in, but first we want to solve #396)

Thank you I will take a look into this

How can I pass options to rufus_scheduler instance inside SidekiqScheduler:Scheduler? SidekiqScheduler:Scheduler seems to be getting its options from yaml. Let me know if I am overlooking something

Doesn't this work? ⬇
rufus_scheduler_options:
  scheduler_lock: <%= RedisLock.instance %>

We want one instance to be able to schedule at a time but if that instance goes away another instance should be able to take that role.

Then I think that you want to pass along a trigger_lock strategy, no? https://github.com/jmettraux/rufus-scheduler#trigger_lock
From the description of the scheduler_lock

The scheduler lock is an object that responds to #lock and #unlock. The scheduler calls #lock when starting up. If the answer is false, the scheduler stops its initialization work and won't schedule anything.

while the trigger_lock

The trigger lock in an object that responds to #lock. The scheduler calls that method on the job lock right before triggering any job. If the answer is false, the trigger doesn't happen, the job is not done (at least not in this scheduler).

So I think that what you're looking for is a trigger lock and not a scheduler lock....

Key will expire in 5 min. (this could be shorter) So if remove_instance_from_queue is not called redis will remove the key. We could also create a thread that just keeps checking if key is set if not instance will set the key meaning they will declare themselves as scheduler amongs other hosts.

🤦♂ Didn't see the expire!

@marcelolx thanks for engagement,

Doesn't this work? ⬇

It doesn't work because yml is loaded before the class itself so it throws undefined class error, maybe there is a trick to overcome this problem.

Then I think that you want to pass along a trigger_lock strategy, no?

We tried trigger_lock as well but because of https://github.com/jmettraux/rufus-scheduler/issues/130 there were jobs duplicated. (we believe)

Thanks for the feedback @eldemcan, I'll keep an eye on that issue.
And once I work on supporting a redis lock strategy I'll see if we can allow users to set a trigger_lock/scheduler_lock without having to patch sidekiq-scheduler!

And once I work on supporting a redis lock strategy

I've made one for myself. You may be interested :)
https://github.com/bibendi/schked/pull/31/files

authors: bibendi bpo eldemcan marcelolx mgoggin rvyas

repo: moove-it/sidekiq-scheduler


text:
High utilisation of memoy

I use this library in my project. I have more than 600 tables in my application. I split them into multiple contexts. This loads all the views into the memory and it consumes more than 500MB of server memory. Why is it keeping the views in the memory?

This is not specific to this library but to EF. Any EF query/command (besides SqlQuery/SqlCommand which bypass EF pipeline) requires views. This is library is just caching views generated by EF and loading them at startup to improve the start up time. Without the library EF would have to generate the views each time the application starts (on first request) and with 600 tables it can actually make a difference but the views are exactly the same so memory usage will be the same. If you however see a difference in memory between when using EFInteractive views and when not using EFInteractive views let me know, and possibly provide dumps.

thanks. I have memory dump file but it is 1.2 GB. How would i upload this to you? When i selected heap view, it shows like this.
ConcurrentDictionary<DbMappingViewCacheFactory, StorageMappingItemCollection> 279 MB
ConcurrentDictionary+Tables<DbMappingViewCacheFactory, StorageMappingItemCollection> 279 MB
ConcurrentDictionary+Node<DbMappingViewCacheFactory, StorageMappingItemCollection> 279 MB
StoragemappingItemCollection 279 MB.

That would be here. Can you check if anything else is holding on to this instance of StorageMappingItemCollection? It's been a while since I wrote this code so I don't remember why I need to keep this but it might be an actual leak if the only thing that keeps the storageMappingItemCollection alive is the dictionary.
I will try to look into this in the coming days to see if the mapping item collection can be cleaned somehow when it is no longer used.

Any idea why it keeps multiple instance of dictionary object? Shall i dispose the dictionary object after instantiating it?

I have not had a chance to look at this yet. Sorry.

repo: moozzyk/EFInteractiveViews


text:
GetSteamFriendAvatar Node Error

Every time we compile the project the node seems to have an error which gets fixed when we refresh the node.

That sounds like blueprint corruption? Have you tried deleting the node entirely, compiling, then adding it back?

repo: mordentral/AdvancedSessionsPlugin


text:
Calling ProgressBar.complete() exhausts all available memory

Simple example:
import peschke.console.progressbar.ProgressBar
import scala.concurrent.ExecutionContext.Implicits.global

object Test extends App {
  val pb = ProgressBar(totalCount = 20000)
  pb.complete()
  Thread.sleep(9000000)
}

Expected: Constant memory usage
Actual: Explosion 💥

False alarm: the version of this library I found copypasted in our codebase had this line changed from .takeUntil to .takeWhile. With dire consequences for my sanity.

Yep, that would do it.
I'd highly recommend using JitPack.io to avoid copy-paste errors.
I just pushed version 1.4.0, which switches to using this instead of an SBT dependency internally, and it works really well. The first time sbt update is run for a particular version it'll probably timeout, as it needs to build the jar, but after that there doesn't seem to be a noticeable difference in speed between that and the other dependencies.

authors: kaishh morgen-peschke

repo: morgen-peschke/scala-progress-bar

license: mit

license_source: bigquery


text:
motioneye

I installed motioneye for the camera but I would also like to include it on homebrige,
I did install the plugin using docker and add the config  :
{
"platform": "rpi-camera",
"cameras": [
{
"name": "Pi Camera"
}
here is the result
[2018-4-10 14:54:29] Loaded plugin: homebridge-smartthings
homebridge_1  | [2018-4-10 14:54:29] Registering platform 'homebridge-smartthings.SmartThings'
homebridge_1  | [2018-4-10 14:54:29] ---
[2018-4-10 14:54:30] [rpi-camera] Initializing rpi-camera platform...
homebridge_1  | [2018-4-10 14:54:30] Loading 0 accessories...
homebridge_1  | --set-ctrl rotate=0
homebridge_1  | --set-ctrl vertical_flip=0
homebridge_1  | --set-ctrl horizontal_flip=0
homebridge_1  | error while setting bitrate: spawn v4l2-ctl ENOENT
homebridge_1  | error while setting bitrate: spawn v4l2-ctl ENOENT
homebridge_1  | error while setting bitrate: spawn v4l2-ctl ENOENT
homebridge_1  | [2018-4-10 14:54:30] Pi Camera is running on port 40415.
I have no camera added

see #16 and #26

repo: moritzmhmk/homebridge-camera-rpi


text:
Is it possible for Row to cast column values to PHP natives?

I noticed when I get a Row instance (from fetch(), say), even numeric columns (in the database) are returned to string. I know this isn't LessQL's fault, but seeing other ORMs do the cast-to-native bit for the developer is this something I missed in LessQL or is it something that's yet to be worked on?
Otherwise enjoying working with LessQL!:

Thank you :) yeah, some sort of "type hinting" is currently missing. I'll put this on the list for v1, thanks again!

Rushes to releases tab to see how close we are to v1....

authors: ihatehandles morris

repo: morris/lessql


text:
🛑 Bama is down

In 7e37996, Bama (https://bama.design) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Bama is back up in 895d4bf after 6 minutes.

repo: mortonpepper/upptime-upptime


text:
Citing foyer?

Do you guys have something we should cite for this effort yet, or just the github repo?
Thanks.

Nothing yet, but there's a paper or two in the works.

There are two papers in the works, one which should hopefully be submitted soon.  For now, along with the github repo, you can cite this conference paper:
Iacovella, C. R.; Sallai, J.; Klein, C.; Ma, T. Idea Paper : Development of a Software Framework for Formalizing Forcefield Atom-Typing for Molecular Simulation. In 4th Workshop on Sustainable Software for Science: Practice and Experiences (WSSSPE4); 2016.
http://ceur-ws.org/Vol-1686/WSSSPE4_paper_35.pdf
We published this paper a few months ago that uses the formalism to distribute a forcefield for PFPEs:
http://pubs.acs.org/doi/abs/10.1021/acs.jpcb.7b00891
Where we used zenodo to generate a doi for the github repo that contained the forcefield and various tests (sort of our first test of using the format and software to aid in dissemination):  http://dx.doi.org/10.5281/zenodo.583310

We also have a poster available on Fig Share from the  SSI-SSE PI meeting.
Iacovella, Christopher; Sallai, Janos (2017): SI2-SSE: Development of a Software Framework for Formalizing ForceField Atom-Typing for Molecular Simulation. figshare.
https://doi.org/10.6084/m9.figshare.4573048.v1
And yeah, the landing page should probably be updated to reflect this info.

Any updates on this? Maybe a preprint? :) (And would love to see the authoritative info on the landing page.)

@davidlmobley Not much new to report unfortunately. However, we are prioritizing the Foyer paper, so we hope to have this completed soon. Additionally, we plan to setup a Github-hosted website for Foyer (similar to what we currently have for mBuild) that will contain a section on how to properly cite. We'll keep you posted!

@davidlmobley just in case it hasn't come across your radar, we have a preprint up https://arxiv.org/abs/1812.06779
Added a link to our README in #202 but I'll keep this open until it's published

Thanks, saving for my records!

authors: chrisiacovella davidlmobley mattwthompson summeraz

repo: mosdef-hub/foyer


text:
Add car parking routing profile

Its best to review this PR commit based, since i tried to group the changes logically together.
All in all multiple things are done in this PR:
Extract is_parking property from osm data into our own data model.
This works semi optimal, since a lot of parking lots don't have nodes connected to the rest of the street network. Tried to check for ways marked as parking connected to accessible nodes, so we can also tag them, but this approach hit exactly 0 times when executed over the hessen data set. Therefor i just keep the simple extraction for now, since the resulting data set is good enough to test parking based routing profiles.
Additional Debug Information
For better debugging the popup logic was completely rewritten. It now shows features grouped by layers and switching between them in the same layer is also possible.

This is easier to use that the previous approach with multiple overlaying popups.
Also improved the path rendering, visualizing the currently use drive mode (foot, bike, car) and the relative cost, where relative cost = cost/distance and then interpolated between colors.

The inner path shows the used mode, (light blue = foot; blue = car) and the path outline the relative cost. It is visible, that the relative cost of going by foot, is pretty high. Most of the time its above 1 and therefor red, while driving by car has a very low relative cost.
It is also now possible to highlight certain node and edges by selecting a value which must be true for them.

Also fixed error handling, so we get now proper error message:

Hybrid Routing Model
Implemented an asymmetric hybrid routing profile. This profile starts the user by car, transition him from car to foot in a parking spot and route the remaining way by foot. This simulates a user going for a trip to some location by car.
To account for search direction resolve(..) and is_reachable(...) had to be made aware of it. These methods are used to get start nodes, start costs and end nodes respectively.
We ignore here the way_cost function here for simplicity and control the starting node via resolve(..). This lead to slight differences between the car profile and hybrid profile, in the routing path from starting location to the first node. Changing way_cost would result in large code rewrites to keep parameter and function purpose accurate, which we will do as soon as the generalized approach gets implemented.
Since we want to get car nodes as start nodes when going forward and foot nodes when going backward, this change was necessary. Same concept applies in reverse for is_reachable.
When looking for adjacent nodes it is also necessary to include the Search Direction, not only for car routing, but also to transition appropriately between car and foot modes. We transition normally from car to foot nodes when going forward, but have to transition from foot to car nodes when going backwards. Outside of transition the default routing logic is applied as demonstrated in foot_profile.h and car_profile.h.
The logic got implemented alongside the current one while avoiding a bigger rewrite to route.h. This changes as soon as a generalized multi modal routing algorithm gets implemented.

Update 2.0
Summary:

fixed visited nodes not highlighting 4ddba7e60c3b1d5e116787eccbd48e5b1d21c4a0
added highlighting of visited nodes for other profiles c983df8be8637ad140a330c016b52d8dfb4acc86
fixed car_parking 7538969c3860e65a8152fa4e591ba31048d9f42c
updated behavior of level highlighting on the map 25d219452b2633cff0b54f6845a666e504960db9)

Visited nodes highlighting 4ddba7e60c3b1d5e116787eccbd48e5b1d21c4a0, c983df8be8637ad140a330c016b52d8dfb4acc86
Re-enabled highlighting of visited nodes. Also had a painful experience learning the difference between ´auto´ and ´auto&´ while debugging haha.
Nodes get now highlighted again, if they were visited.

Nodes now also get highlighted for there different routing profiles:

To be compatible with the selection highlighting, selected nodes are now highlighted in "gold". visited nodes just get a golden stroke.

car parking wheelchair version 7538969c3860e65a8152fa4e591ba31048d9f42c
Was a bit tricky, had to do 3 things here:
initializing node index with ´node_idx_t::invalid()´
https://github.com/motis-project/osr/pull/15/commits/7538969c3860e65a8152fa4e591ba31048d9f42c#diff-5ebdfd9f43d5edbf6636c40379a4cc67b8e4685e31fb385956b693cf04b50267R73-R78
The problem here was, that we check in the ´entry.pred(...)´ if the node index of the predecessor  is invalid, returning ´std::nullopt´ if that is the case.
Entries having a starting node as a predecessor have random values in the corresponding ´pred_[idx]´ entry, since the the node index in starting nodes never got set.
reversing the search direction check in ´is_dest_reachable´
https://github.com/motis-project/osr/pull/15/commits/7538969c3860e65a8152fa4e591ba31048d9f42c#diff-5ebdfd9f43d5edbf6636c40379a4cc67b8e4685e31fb385956b693cf04b50267R274-R276
When reconstructing the path, the search direction gets reversed in the ´best_candidate´ function of ´route.h´. We therefor have to do this check in reverse.
Add level information to car nodes.
https://github.com/motis-project/osr/pull/15/commits/7538969c3860e65a8152fa4e591ba31048d9f42c#diff-5ebdfd9f43d5edbf6636c40379a4cc67b8e4685e31fb385956b693cf04b50267R188-R246
We need level information in all our nodes, so ´adjacent´ in ´foot´ has the required information to properly determine, which node is reachable.  My solution is rather crude currently an we have again duplicated logic, but this can be a starting point.
So far the profile works. I am not 100% sure that i did not miss anything, but my testing attempts were successful so far.
Update level rendering behavior. 25d219452b2633cff0b54f6845a666e504960db9
The behavior here was quite frustrating, so i addressed it while testing the wheelchair car parking profile.
Filtering is now fully controlled by the map. Instead of reapplying the style, we simply set the filter for style, graph and path layers at runtime. This approach eliminates the need to reload the graph and paths when changing levels. To display different graph nodes for various levels, we now request all nodes at once instead of sending level-specific nodes each time we request debug graph data. Although this may slightly increase the load, it is offset by avoiding repeated requests with each level change.
This change is open for discussion and can be reverted if necessary.

Great job! Thank you very much! :partying_face:

source: gharchive/pull-request

authors: djfhe felixguendling

repo: motis-project/osr


text:
🛑 manfred.life is down

In 1559640, manfred.life (https://manfred.life/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: manfred.life is back up in 984d25a after 787 days, 5 hours, 54 minutes.

repo: moul/uptime


text:
incorrect diameters or surface-brightness profiles in SGA-2020

Related to https://github.com/moustakas/SGA/issues/48, let's track galaxies with incorrect diameters or surface-brightness profiles here so they can be checked in the next version of the atlas.
From https://github.com/moustakas/SGA/issues/60#issue-1398129318:

NGC 55 + IC1537 - SGA ellipse is not big enough and misses fluxes
NGC253 - SGA ellipse not big enough
NGC4406 + NGC4402 - SGA ellipses look small
NGC4472 - SGA ellipse looks small
IC5152 - SGA ellipse looks ok but wrong axis ratio

The following objects are in globular clusters and have over-estimated; they probably should be removed from the next SGA version:

https://sga.legacysurvey.org/group/DR8-3225p122-20657_GROUP
DR8-2056p285-107 - https://www.legacysurvey.org/viewer?ra=205.5741&dec=28.4906&layer=ls-dr9&zoom=15&sga&sga-parent
DR8-2056p285-12718 - https://www.legacysurvey.org/viewer?ra=205.5532&dec=28.4685&layer=ls-dr9&zoom=14&sga-parent&sga

DDO113 should be redone
Group: DDO113
RA Dec=183.742033 36.218418
D(26)=1.656 arcmin, b/a=0.67, PA=45.0 deg
Type: dIrr , Redshift=0.0009

UGC07559
Group: UGC07559
RA Dec=186.772328 37.143684
D(26)=3.548 arcmin, b/a=0.65, PA=145.5 deg
Type: I , Redshift=0.0007
Very underestimated diameter and LEDA is truly accurate

The galaxy is significantly overestimated due to big galaxy
NGC2694
Group: NGC2693_GROUP
RA Dec=134.246940 51.331944
D(26)=2.163 arcmin, b/a=0.69, PA=68.2 deg
Type: E , Redshift=0.0169

authors: TriShotFlurry moustakas

repo: moustakas/SGA


text:
Error parsing '[package]' section of manifest, VSCode

I installed the move-analyzer following official documentation https://marketplace.visualstudio.com/items?itemName=move.move-analyzer . For some reason when i open .move file it shows  Error parsing '[package]' section of manifest

Also, when i open .move file "go to the definition" , "Go References" and others features doesn't work, but seems like i have highlights.

I tried to fix it about 3 days by deleting and installing all the packages. Please community, if someone had the same trouble or you know reasons why this happen i will be appreciate for any information!

The Move analyzer in the Move repo here is not maintained. Rather you find an evolved and maintained analyzer by searching for it in VS Code.

The Move analyzer in the Move repo here is not maintained. Rather you find an evolved and maintained analyzer by searching for it in VS Code.

What does mean "here"? In the VSCode or my project? The Move Analyzer actually links here

Both the Aptos and Sui move analyzers have been forked from here and are currently maintained by Movebit. I don't know exactly where to find the Sui version, but the Aptos one is here: https://github.com/movebit/move/tree/aptos-move-analyzer. You need to search for "aptos move" or similar in VS (I'm not a VS user so I can't tell you how to exactly do this).
In general this is really not the right repo here for user question. You should ask on either the Aptos or the Sui discord channels.

authors: kvitlich wrwg

repo: move-language/move


text:
[Prover] Prover isn't compatible to the newest Boogie (2.15.9) due to its breaking change

Boogie (2.15.9) produces the following error for Prover's default output.bpl. It seems that Boogie does not support # as the field access notation. The new notation is -> (for example: https://github.com/boogie-org/boogie/blob/master/Test/datatypes/field_access_correct.bpl).
boogie -doModSetAnalysis -printVerifiedProceduresCount:0 -printModel:1 -enhancedErrorMessages:1 -monomorphize -proverOpt:O:model_validate=true -proverOpt:PROVER_PATH=/Users/jpark/bin/z3 -proverOpt:O:smt.QI.EAGER_THRESHOLD=100 -proverOpt:O:smt.QI.LAZY_THRESHOLD=100 -vcsCores:4 output.bpl
output.bpl(39,14): Error: use of undeclared function: l#Vec
output.bpl(40,8): Error: use of undeclared function: v#Vec
output.bpl(44,4): Error: use of undeclared function: v#Vec
output.bpl(48,4): Error: use of undeclared function: l#Vec
output.bpl(52,4): Error: use of undeclared function: l#Vec
output.bpl(56,14): Error: use of undeclared function: l#Vec
output.bpl(57,8): Error: use of undeclared function: v#Vec
output.bpl(61,14): Error: use of undeclared function: l#Vec
output.bpl(65,29): Error: use of undeclared function: v#Vec
output.bpl(65,46): Error: use of undeclared function: v#Vec
output.bpl(71,27): Error: use of undeclared function: l#Vec
output.bpl(71,38): Error: use of undeclared function: v#Vec
output.bpl(71,49): Error: use of undeclared function: l#Vec
output.bpl(71,60): Error: use of undeclared function: v#Vec
output.bpl(81,14): Error: use of undeclared function: l#Vec
output.bpl(83,50): Error: use of undeclared function: v#Vec
output.bpl(88,14): Error: use of undeclared function: v#Vec
output.bpl(100,8): Error: use of undeclared function: v#Vec
output.bpl(100,29): Error: use of undeclared function: l#Vec
output.bpl(104,14): Error: use of undeclared function: v#Vec
output.bpl(105,33): Error: use of undeclared function: l#Vec
output.bpl(109,14): Error: use of undeclared function: l#Vec
output.bpl(110,42): Error: use of undeclared function: v#Vec
output.bpl(143,4): Error: use of undeclared function: l#Multiset
output.bpl(147,16): Error: use of undeclared function: l#Multiset
output.bpl(148,16): Error: use of undeclared function: v#Multiset
output.bpl(149,13): Error: use of undeclared function: v#Multiset
output.bpl(154,17): Error: use of undeclared function: l#Multiset
output.bpl(155,17): Error: use of undeclared function: l#Multiset
output.bpl(156,28): Error: use of undeclared function: v#Multiset
output.bpl(156,46): Error: use of undeclared function: v#Multiset
output.bpl(160,5): Error: use of undeclared function: l#Multiset
output.bpl(161,20): Error: use of undeclared function: v#Multiset
output.bpl(165,5): Error: use of undeclared function: l#Multiset
output.bpl(165,23): Error: use of undeclared function: l#Multiset
output.bpl(166,20): Error: use of undeclared function: v#Multiset
output.bpl(166,41): Error: use of undeclared function: v#Multiset
output.bpl(170,4): Error: use of undeclared function: v#Multiset
output.bpl(201,4): Error: use of undeclared function: v#Table
output.bpl(205,4): Error: use of undeclared function: l#Table
output.bpl(210,4): Error: use of undeclared function: e#Table
output.bpl(214,10): Error: use of undeclared function: v#Table
output.bpl(214,30): Error: use of undeclared function: e#Table
output.bpl(214,53): Error: use of undeclared function: l#Table
output.bpl(221,10): Error: use of undeclared function: v#Table
output.bpl(221,30): Error: use of undeclared function: e#Table
output.bpl(221,53): Error: use of undeclared function: l#Table
output.bpl(226,10): Error: use of undeclared function: v#Table
output.bpl(226,22): Error: use of undeclared function: e#Table
output.bpl(226,46): Error: use of undeclared function: l#Table
output.bpl(269,17): Error: use of undeclared function: lb#$Range
output.bpl(269,49): Error: use of undeclared function: ub#$Range
output.bpl(274,3): Error: use of undeclared function: lb#$Range
output.bpl(274,28): Error: use of undeclared function: ub#$Range
output.bpl(341,4): Error: use of undeclared function: v#$Mutation
output.bpl(346,14): Error: use of undeclared function: l#$Mutation
output.bpl(346,30): Error: use of undeclared function: p#$Mutation
output.bpl(350,14): Error: use of undeclared function: l#$Mutation
output.bpl(350,40): Error: use of undeclared function: p#$Mutation
output.bpl(355,4): Error: use of undeclared function: l#$Mutation
output.bpl(355,27): Error: use of undeclared function: l#$Mutation
output.bpl(355,49): Error: use of undeclared function: p#$Mutation
output.bpl(355,72): Error: use of undeclared function: p#$Mutation
output.bpl(361,4): Error: use of undeclared function: l#$Mutation
output.bpl(361,27): Error: use of undeclared function: l#$Mutation
output.bpl(362,15): Error: use of undeclared function: p#$Mutation
output.bpl(363,15): Error: use of undeclared function: p#$Mutation
output.bpl(374,4): Error: use of undeclared function: l#$Mutation
output.bpl(374,27): Error: use of undeclared function: l#$Mutation
output.bpl(375,15): Error: use of undeclared function: p#$Mutation
output.bpl(376,15): Error: use of undeclared function: p#$Mutation
output.bpl(394,4): Error: use of undeclared function: l#$Mutation
output.bpl(394,23): Error: use of undeclared function: l#$Mutation
output.bpl(398,4): Error: use of undeclared function: is#$Global
output.bpl(398,15): Error: use of undeclared function: l#$Mutation
output.bpl(402,4): Error: use of undeclared function: l#$Mutation
output.bpl(406,4): Error: use of undeclared function: a#$Global
output.bpl(406,14): Error: use of undeclared function: l#$Mutation
output.bpl(413,4): Error: use of undeclared function: domain#$Memory
output.bpl(418,4): Error: use of undeclared function: contents#$Memory
output.bpl(423,12): Error: use of undeclared function: domain#$Memory
output.bpl(423,42): Error: use of undeclared function: contents#$Memory
output.bpl(428,12): Error: use of undeclared function: domain#$Memory
output.bpl(428,43): Error: use of undeclared function: contents#$Memory
output.bpl(433,12): Error: use of undeclared function: domain#$Memory
output.bpl(433,35): Error: use of undeclared function: domain#$Memory
output.bpl(434,12): Error: use of undeclared function: contents#$Memory
output.bpl(434,37): Error: use of undeclared function: contents#$Memory
output.bpl(697,16): Error: use of undeclared function: lb#$Range
output.bpl(697,30): Error: use of undeclared function: ub#$Range
output.bpl(807,21): Error: use of undeclared function: l#$Mutation
output.bpl(807,47): Error: use of undeclared function: p#$Mutation
output.bpl(982,22): Error: use of undeclared function: $addr#$signer
output.bpl(989,11): Error: use of undeclared function: $addr#$signer
output.bpl(994,4): Error: use of undeclared function: $addr#$signer
95 name resolution errors detected in output.bpl

This is the PR which introduces the new syntax and documents it: https://github.com/boogie-org/boogie/pull/624#pullrequestreview-1128852873

authors: junkil-park wrwg


text:
Executing multiple trajectories with different controllers is not supported

Description
Hi,
I'm trying to move 4 move groups on 1 robot simultaneously.  I have found out that it is not easy to do so as all of the 4 motion plans pipe into the same action server. However there were some suggestions to use the async_move() function of the move_group class which should provide this functionality. This can be activated by setting group.go(wait=False). However executing this did not change any behavior, all of the 4 groups are still moved one after another. Any help will be appreciated.
Your environment

ROS Distro: Melodic
OS Version: Ubuntu 18.04
Source or Binary build? Source
If binary, which release version?
If source, which branch?

Expected behaviour
Groups should be moved simultaneously
Actual behaviour
Same behavior as with wait=True, groups move one after another

I'm trying to move 4 move groups on 1 robot simultaneously.

What sort of robot is this? An industrial robot with multiple motion groups on a single controller, or a custom job with multiple controllers?

I am using 4 Panda Arms which I have attached to a plane which works as a base link (just as a simulation in Gazebo).
This is my controller file: ros_controllers.txt
For each move group (panda arm) there is 1 controller configured.

So multiple controllers?
I'm a bit puzzled by this part of your description:

I have found out that it is not easy to do so as all of the 4 motion plans pipe into the same action server.

If you have multiple pandas, with multiple controllers, and are not using a combined hw ros_control setup/the multi-robot support in the Franka software (or something similar), wouldn't you have multiple action servers?

Yes indeed. I have 4 action servers to give commands to the controllers, thats why I am able to control them each on its own. I just read https://answers.ros.org/question/317028/how-run-multiple-move_group-for-different-robots-in-single-system/ and assumed that MoveIt is going to pipe each motion plan into an action server (which might be wrong) before adressing the controller action servers. Sorry for the unclear description.

I can't help you with the async_move(..) I'm afraid, but each Franka driver instance exposes an action server.
So MoveIt would submit action goals to each individual action server.
With such a setup, synchronous execution of trajectories would be inherently impossible.
If "somewhat simultaneous" would be enough, that should be possible.

If you need them actually synchronized, I would suggest using a single planning group with all your pandas inside it.
Are you sure that 4 move_group nodes are started up? Or are you only starting 4 move_group_interfaces in your code?

Thanks anyways @gavanderhoorn. What I am trying to create is a robot with 4 arms that simulates an improved process of additive manufacturing. The goal of reducing the manufacturing process time is the reason that all of the 4 arms need to be working at the same time. If they have a delay of a few seconds behind each other that won't be a problem but obviously if there is only 1 arm working at all times there is no reason to use 4 of them.
@felixvd It looks like by default the moveit_config package generates 1 move_group action server, in my script I create 4 instances of the MoveGroupCommander class one for each arm. Is this a wrong approach?

Well, not "wrong", but you won't be able to run 4 robots asynchronously with that setup. I assume this is what happened:

You have 8 different planning groups set up inside your moveit_config (one for each Panda and one for each hand)
You roslaunch moveit_planning_execution.launch or move_group.launch, which creates one move_group instance
Your script node creates 4 instances of the MoveGroupCommander class, which all connect to the same move_group
When you call async_move through one of the MoveGroupCommander objects, your move_group connects to one of the robot controllers (follow_joint_trajectory) and waits for the trajectory to be executed. Your MoveGroupCommander returns immediately for you to continue in your script.
You attempt to call async_move through another MoveGroupCommander object, but your move_group is busy waiting on the robot controller, so it either pre-empts that action or ignores your new command (I think it is the former, but I am not sure)

If you want to run the 4 robots asynchronously in the way you describe, my understanding is that you will need to launch 4 move_group nodes, so that each can connect to their own robot. The moveit_config and the planning groups defined in the package can be the same – you just have to be careful on your own not to use the same robot with two move_groups at the same time (this would be actually dangerous, please avoid). Each move_group will not consider the other move_group's plans, although each will be updated with the current position of all the robots. You should make doubly sure that the start state of your plan/trajectory is actually the robot's current state.
The "cleanest" way is probably to namespace the move_group launch file and remap the /joint_states to each of your namespaces so they each receive the robots' states. I am not sure if they can all live in the same namespace. In fact, now that I look at move_group_interface (the MoveGroupCommander just binds to this C++ class), you can't pass in the namespace. I guess you could run a node that creates one MoveGroupCommander in each move_group's namespace, but that seems unnecessarily messy. The other option I can see is to add a ros_namespace argument to the move_group_interface/MoveGroupCommander so that the move_action_client an execute_action_client connect to the correct move_group instance.
I haven't tried this and don't know anyone who has, but I know running planning groups simultaneously is a desirable feature. Pinging @henningkayser, @v4hn to correct if I wrote something completely off the mark. I also wonder if #2078 is related.

Ok I understand a bit better now what the problem is, thanks! You are right, I am launching 1 move_group but 4 MoveGroupCommanders. I have launched the move_group launch file in 4 different namespaces now, however I had to also namespace the joint_state_publisher and robot_state_publisher. The controller_spawner node inside the ros_controllers launch file does not work for now due multiple nodes named the same. Are launchfiles inside launchfiles not automatically launched under the aforementioned namespace?
As in both cases I will have to run 4 move_group nodes is it better to run 4 nodes or launch 4 times the move_group launch file? And regarding the ros_namespace argument, will this have to be added into the source code of the MoveGroupCommander or is there another way?
#2078 looks like it is adressing this issue, hope this feature is available soon.
Thanks again, you already helped a lot!

The controller_spawner node inside the ros_controllers launch file does not work for now due multiple nodes named the same. Are launchfiles inside launchfiles not automatically launched under the aforementioned namespace?

I don't know if the <group ns=... parameter can be nested and if it works for launch files, although I assumed/hoped it would. You should not have to namespace the controllers though. Keep them wherever they were, and try namespacing only the move_group nodes. I'm not sure you need to launch joint_state_publisher and robot_state_publisher in the namespace either if you use remap.

regarding the ros_namespace argument, will this have to be added into the source code of the MoveGroupCommander or is there another way?

As far as I can see, yes, but it should be as simple as adding the namespace in front of the move_group::MOVE_ACTION etc. parameters here. Then you just add a constructor that sets it. The MoveGroupCommander is defined here, but you would edit the wrapped C++ constructor here. Feel free to try it locally. I think it is the easiest way for what you are trying to do, and it would probably be worth a PR if it works well.
I do think this is a workaround though, and I think the move_group should be able to execute multiple trajectories simultaneously if the joint_model_groups are independent. Would like to hear @henningkayser's thoughts since he is one of the most familiar with that part of the codebase I believe.

I don't know if the <group ns=... parameter can be nested and if it works for launch files, although I assumed/hoped it would. You should not have to namespace the controllers though. Keep them wherever they were, and try namespacing only the move_group nodes.

The problem with the controllers is that it seems to be looking for the /move_group action server, which is now called /move_group1/move_group/[...] , /move_group2/move_group/[...] etc. due to the namespaces. Remapping all the topics and the action server back to /move_group from inside the move_group launch file so that the controller client can find it is unefficient but remapping the /move_group server to the 4 new-named instances of move_group from inside the controller launch file is not even possible from my understanding. So in conclusion the controllers can't find the move_group action server after namespacing it and I am not sure how to solve this if I let the controller launch file live in the namespace where it currently is.

As far as I can see, yes, but it should be as simple as adding the namespace in front of the move_group::MOVE_ACTION etc. parameters here. Then you just add a constructor that sets it. The MoveGroupCommander is defined here, but you would edit the wrapped C++ constructor here. Feel free to try it locally. I think it is the easiest way for what you are trying to do, and it would probably be worth a PR if it works well.

With this approach I will still need 4 move_group nodes which will lead to the same problem with the controllers or does this work with only one move_group too?

The controllers advertise follow_joint_trajectory actions, which move_group uses to execute trajectories. Why would they be looking for a /move_group action server? Can you paste the error? Have you tried launching the controllers in each namespace as well?

With this approach I will still need 4 move_group nodes which will lead to the same problem with the controllers or does this work with only one move_group too?

Yes, you will still need 4 move_group nodes if you want to execute 4 trajectories simultaneously (although it would be nice if this limitation was solved in the future).

[ INFO] [1599482396.609129695, 3.730000000]: Failed to call service get_planning_scene, have you launched move_group or called psm.providePlanningSceneService()?
[ INFO] [1599482396.609518646, 3.730000000]: Constructing new MoveGroup connection for group 'printer_arm1' in namespace ''
[ WARN] [1599482402.573232859, 5.233000000]: Waiting for printer/printer_arm1_controller/follow_joint_trajectory to come up
[ERROR] [1599482426.627978181, 10.203000000]: Unable to connect to move_group action server 'move_group' within allotted time (30s)
[ INFO] [1599482426.634298254, 10.204000000]: Constructing new MoveGroup connection for group 'printer_arm1' in namespace ''
[ WARN] [1599482431.020203508, 11.233000000]: Waiting for printer/printer_arm1_controller/follow_joint_trajectory to come up
[ERROR] [1599482455.143529187, 17.233000000]: Action client not connected: printer/printer_arm1_controller/follow_joint_trajectory
[ERROR] [1599482456.657825789, 17.636000000]: Unable to connect to move_group action server 'move_group' within allotted time (30s)
[ INFO] [1599482456.658144226, 17.636000000]: Constructing new MoveGroup connection for group 'printer_arm1' in namespace ''
This is the error I get which will come up for every controller that I am trying to launch.
Haven't tried out launching them in each namespace yet but thats what I was going to try out next.

Yes, try that. And note that you can format code with ```, if you paste more terminal output.

Did you manage to get this running or were there more difficulties?

I have not been able to test it yet because of an unrelated error that popped up but I will come back to this as soon as it's fixed.

I do think this is a workaround though, and I think the move_group should be able to execute multiple trajectories simultaneously if the joint_model_groups are independent. Would like to hear @henningkayser's thoughts since he is one of the most familiar with that part of the codebase I believe.

AFAIK, there is no way to do this with MoveGroup for several reasons:

The MoveGroupAction is run by a SimpleActionServer only supporting one request at a time
The TrajectoryExecutionManager only runs a single execute thread at a time
The MoveGroup's planning scene is read locked for each planning request because changes like motions of other groups could invalidate the computed trajectory
Executing multiple trajectories at the same time can easily lead to collisions because there is no trajectory validation/monitoring in place that accounts for already running motions

The single MoveGroup way to solve this would really be to define a planning group that includes all arms. Of course you need an IK solver and a planner to support this or you need to merge the different trajectories by hand. Otherwise, running multiple MoveGroup nodes should work with proper namespacing, but there could still be some issues with global parameters or topics. Keep in mind that arm-to-arm collision checking and syncing of the planning scenes can still be tricky and error-prone.
Another thing that might be worth looking into is to execute preplanned trajectories directly by sending FollowJointTrajectory actions to the ros controllers (of course you have to rule out arm-to-arm collisions first). This would bypass MoveGroup's trajectory execution manager so you won't have any trajectory monitoring in this case, but to me this seems like the easiest and safest solution.

Thanks for posting here as well, after the discussion in the meeting. This is a very interesting topic and this post got sort of long. Sorry in advance.
You mentioned that the TrajectoryExecutionManager only runs a single thread. I have read some of the code today, and it is true that only one thread is launched at a time - in pushAndExecute or execute. But the fact that execution is in a separate thread makes me think that much of the heavy lifting towards simultaneous execution is already done.
As you said, the MoveGroup's move and execute capabilities only run a SimpleActionServer, which only support one request. While it is true that each new goal causes the old action to be preempted, and thus a SimpleActionClient waiting on the previous goal would return, we could check which joints are part of the new goal, and keep executing the previous trajectory if the new one does not use any of the same joints. We would then return from the newest goal only when all trajectories have been executed.
The plan service capability does get a planning_scene_monitor::LockedPlanningSceneRO, which locks the PlanningScene. But while that would affect simultaneous planning and execution, it should not be an obstacle to executing multiple trajectories.
It is also true that there is currently no trajectory validation/monitoring for motions that are being executed. But there is executeAndMonitor which is connected to the "Replanning" checkbox in our Rviz panel, does monitor the remaining path of a trajectory for collisions and has this entertaining comment questioning if it should live in trajectory_execution_manager. It seems to me that this part of the code is orphaned but could be made useful again. Maybe @BryceStevenWilley can justify using some hours from Realtime Robotics for this :) For this sort of optimized use case, I think the user should be responsible for ensuring that the trajectory is not dangerous, but their controller is fast enough that this monitoring would work at sufficient speed.

Otherwise, running multiple MoveGroup nodes should work with proper namespacing, but there could still be some issues with global parameters or topics. Keep in mind that arm-to-arm collision checking and syncing of the planning scenes can still be tricky and error-prone.

It has been a long time since I have tried that, but my lasting impression was that move_group is not trivial to put into a namespace. You need to pipe robot_description and the joint state updates to it somehow (as well as the other groups' planning scenes??), and I don't know if anyone has ever made a good tutorial. The smoothest solution I found (and have been using since) is to put all the robots into the robot_description and separate them into planning groups. For humanoid robots and other naturally multi-arm robots (including work cells), I think that this is still the most sensible method. It also seems to me the most sensible way forward to give move_group the tooling to move multiple groups at once, and then (maybe, one day) methods to update the robot/scene for events like end effector changes.
At least, that seems more feasible to me than namespacing each arm of a humanoid robot and trying to keep their planning scenes synchronized. But anyone with opinions about this architecture choice is warmly invited to comment.

Another thing that might be worth looking into is to execute preplanned trajectories directly by sending FollowJointTrajectory actions to the ros controllers (of course you have to rule out arm-to-arm collisions first). This would bypass MoveGroup's trajectory execution manager so you won't have any trajectory monitoring in this case, but to me this seems like the easiest and safest solution.

Just for the record, I agree, and this is part of what I will be trying next myself.

Thanks for answering to this. I think in my case sending preplanned trajectories directly to the controllers seems very viable as I am able to split the space for the arms into 'workspaces' so that they won't collide with each other ideally. I think I even saw a function to define these workspaces in the MoveGroupCommander. However, the purpose is to 'print' filament by adding flat boxes along the followed cartesian path. From my understanding that won't be possible because the planning scene needs to be locked if I use the mentioned approach. Additionally I was thinking to use the Perception feature for dynamic collision avoidance so that the arms would stop the trajectory if another arm enters a foreign workspace. Would that still be possible? Is locking the scene even necessary if the robot is split into workspaces and the (ideally) few cases of possible collisions are filtered out by perception?

Hello guys, this issue seems to join lots of features, it took me a while to read all the documentation related to it.

Additionally, I was thinking to use the Perception feature for dynamic collision avoidance so that the arms would stop the trajectory if another arm enters a foreign workspace.

I took a look at the tutorial for Perception  and I wonder if it would be necessary to add the arm as a collision object for this to work. It can be a nice implementation, but I think the solution, as pointed out in GSoC's proposal of project is to do this avoidance dynamically.
Is there a way to extract the arm's movement functions without spoiling the simulation? My concern about this is creating lag or weird bugs.

Let's assume a single URDF with two robot arms (planning groups). Both arms are already part of the collision environment, so they don't need to be added as collision objects.
I'm not sure what you mean by "movement functions" or "spoiling the simulation". If you mean the trajectory, the TrajectoryExecutionManager would know all trajectories that are being executed, so you could access the current and future position of all planning groups relatively easily.

Hello, going through the comments, it seems that the agreed upon way for simultaneous trajectory execution is by sending FollowJointTrajectory actions to the ros controllers.

The TrajectoryExecutionManager would know all trajectories that are being executed, so you could access the current and future position of all planning groups relatively easily.

If I interpret this correctly, this means that by leveraging the TrajectoryExecutionManager we can check for all potential cases of
collision between multiple arms. Up until this point things look pretty straight forward, is there something else that I need to consider before I start digging into the nitty-gritty of the implementation details?

Hello, going through the comments, it seems that the agreed upon way for simultaneous trajectory execution is by sending FollowJointTrajectory actions to the ros controllers.

This interface will definitely not change, yes.

The TrajectoryExecutionManager would know all trajectories that are being executed, so you could access the current and future position of all planning groups relatively easily.

If I interpret this correctly, this means that by leveraging the TrajectoryExecutionManager we can check for all potential cases of
collision between multiple arms. Up until this point things look pretty straight forward, is there something else that I need to consider before I start digging into the nitty-gritty of the implementation details?

A few thoughts, not only for you:

Yes, when a new trajectory is to be executed, TEM should check for collisions with the currently active trajectories.
The simplest way to implement this seems to be:

When a new trajectory is to be executed and other trajectories are active, create a new "merged" robot trajectory, used only for collision checking.
The merged trajectory should contain the remaining parts of the active trajectories + the new one. This merging will need to be done from scratch I believe.
The merged trajectory can be checked with the isPathValid method of the PlanningScene.

Collision is checked for each sample, so safety is not strictly guaranteed. Bullet offers continuous collision checking, but that's another story. Padding should be used.
The positions of the robots executing active trajectories will not be perfectly accurate, due to delays in each controller and the physical execution. This is another reason to use padding.
Padding might cause collisions with the environment, even though incoming trajectories should have been checked for that already. We could ignore environment collisions by modifying the AllowedCollisionMatrix of the PlanningScene object. (By "environment" I mean stationary robot links)

Finally, importantly:

It is great to start reading and trying, but don't forget that there is no guarantee that a GSoC slot for the project will be assigned to you. Fixing smaller issues first also makes your case and avoids potentially duplicated work.

A few thoughts, not only for you:

Yes, when a new trajectory is to be executed, TEM should check for collisions with the currently active trajectories.

The simplest way to implement this seems to be:

When a new trajectory is to be executed and other trajectories are active, create a new "merged" robot trajectory, used only for collision checking.
The merged trajectory should contain the remaining parts of the active trajectories + the new one. This merging will need to be done from scratch I believe.
The merged trajectory can be checked with the isPathValid method of the PlanningScene.

Collision is checked for each sample, so safety is not strictly guaranteed. Bullet offers continuous collision checking, but that's another story. Padding should be used.

The positions of the robots executing active trajectories will not be perfectly accurate, due to delays in each controller and the physical execution. This is another reason to use padding.

Padding might cause collisions with the environment, even though incoming trajectories should have been checked for that already. We could ignore environment collisions by modifying the AllowedCollisionMatrix of the PlanningScene object. (By "environment" I mean stationary robot links)

Thank you for the pointers, especially the idea of using merged trajectories, I will try to keep them in mind while coming up with a solution.

Finally, importantly:

It is great to start reading and trying, but don't forget that there is no guarantee that a GSoC slot for the project will be assigned to you. Fixing smaller issues first also makes your case and avoids potentially duplicated work.

Got it, as mentioned earlier(discord), I have been able to run multiple robot arms. I will proceed to write a short tutorial for this and open a PR against #465

I did not read this thread before because the name did not at all represent the discussed problem, but @felixvd pointed me here in another related issue.
Missing support for multiple simultaneous trajectories It is a (among maintainers) well-known shortcoming of the execution engine. As mentioned here multiple times, clearly, it should be possible to send trajectories to different controllers and sending them directly to the controllers is possible.
Path and execution monitoring could benefit from bundling the requests through, especially to avoid collisions due two multiple arms moving.
Henning mentioned many points above, but from my perspective the main limiting factor is the current choice to implement ExecuteTrajectory as a SimpleActionServer. It provides such a neat abstraction over the general action server design that very few people using ROS have actually ever seen a NonSimple ActionServer. But it structurally limits the interface to one request at a time and we it's wrong for this interface.
I believe the best way forward would be to implement the action as a general ActionServer and work your way down from there.
It is true that the TrajectoryExecutionManager only handles one trajectory at a time, but it's no big deal to change that.
I would expect other changes are required as well, but you only find out once you're there.

I have been able to execute multiple trajectories asynchronously using separate instances of the TrajectoryExecutionManager running in their own thread launched with the std::package_task  construct. An overly simplified snippet of that is as follows:
// declare type aliases
using ExecStatus = moveit_controller_manager::ExecutionStatus;

// declare and initialize moveitcpp
 moveit::planning_interface::MoveItCppPtr planning_interface_ = ... ; // MoveItCpp is only used to gain access to the robot model and planning scene monitor
...

// declare trajectories and controller names
std::vector<moveit_msgs::RobotTrajectory> trajectories = ...
std::vector<std::string> controller_name = {"fake_arm1_controller", "fake_arm2_controller", ...};

// declare vector for storing futures
std::vector<std::shared_future<ExecStatus>> exec_futures;

for(std::size_t i =0; i < trajectories.size(); i++)
{
auto traj = trajectories[i];
std::string controller_name = controller_names[i];

// instantiate controller
trajectory_execution_manager::TrajectoryExecutionManagerPtr traj_exec_mngr = std::make_shared< trajectory_execution_manager::TrajectoryExecutionManager>(
            planning_interface_->getRobotModel(), planning_interface_->getPlanningSceneMonitorNonConst()->getStateMonitorNonConst(), false);

// create packaged task with lambda that executes the trajectory
std::packaged_task< ExecStatus ()> async_task ([traj_exec_mngr, traj, controller_name]() -> ExecStatus{
  traj_exec_mngr->push(traj.joint_trajectory, controller_name);
  traj_exec_mngr->execute([](const moveit_controller_manager::ExecutionStatus& st){
    ROS_INFO_COND(st,">>>> Trajectory completed");
    ROS_ERROR_COND(!st,"Trajectory failed");
  });
  moveit_controller_manager::ExecutionStatus st = traj_exec_mngr->waitForExecution();
  traj_exec_mngr->stopExecution(true); // don't know if this is necessary
  traj_exec_mngr->clear();
  return st;
});

// get shared future and store
exec_futures.push_back(std::shared_future<ExecStatus>(async_task.get_future()));

// move task into new thread
std::thread t(std::move(async_task));
t.detach();
}

// wait for threads to complete
while(ros::ok() && loop_pause.sleep())
{
  if(std::all_of(exec_futures.begin(), exec_futures.end(),[](std::shared_future<ExecStatus>& f){
    std::future_status st = f.wait_for(std::chrono::duration<double>(0.01));
    return st == std::future_status::ready;
  }))
  {
    break;
  }
}

Does this give you an advantage over sending the trajectory directly to the robot driver? It would still leave you without collision checking between the trajectories from what I can see.

Does this give you an advantage over sending the trajectory directly to the robot driver?
It would still leave you without collision checking between the trajectories from what I can see.

It's only a partial way out, but at least it gives you the usual monitoring / online validity checking for each trajectory separately.
It should even find potential future collisions if one robot moves into the executing future trajectory of the other one.

Does it? I read this line to mean that collisions are only re-checked if a collision object is added or changed, since UPDATE_STATE is not included here.

You are right. UPDATE_STATE would have to be added there, but the flag should probably only signal if joints outside the executing JointModelGroup change.
I'm unsure about the resulting computational overhead, so I won't propose to add that logic there just now.
It would be a nice option to have though.
So the only thing you really gain when using the upstream repository is monitoring of the trajectory duration (mostly to catch controllers that fail to respond), but it's just a few lines to get partial collision checking too :cat2:

I've been thinking lightly about this. Instantiating multiple TrajectoryExecutionManagers seems feasible (although I don't know where they would live, since every context only owns one), but either way we need a way to check that a trajectory is safe to execute alongside the current ones, before we change the execute_trajectory action server. To me that is the main limiting factor.
In plan_execution.cpp, isRemainingPathValid steps through an ExecutableMotionPlan to check collisions. If this function took a vector of ExecutableMotionPlan objects as input* and stepped through all of them simultaneously, it could at least roughly check for collisions. "Roughly" because the collisions are checked at each waypoint of the trajectory, and I am not sure if any density on those is guaranteed.
I guess it would be plan_execution::PlanExecution::arePathsColliding(const std::vector<ExecutableMotionPlan>& plans, const std::vector<std::pair<int, int>>& path_segments).
*In an earlier post I thought about merging two ExecutableMotionPlan objects into one to step through them together, but I don't think this makes sense, since each robot would still have its own RobotTrajectory inside.

I was playing around with the idea of @jrgnicho to spawn one TrajectoryExecutionManagers per trajectory and manage their execution in plan_execution, but this would change the logic of the MoveGroupContext (it would need to store a vector of TEMs instead of only one) and probably cause a lot of uncomfortable downstream changes. If the logic was contained within the TrajectoryExecutionManager, migration would be much easier.
Reading the TrajectoryExecutionManager in more detail, it seems like there are two redundant entry points: execute and pushAndExecute. Each uses a thread to walk through a vector of TrajectoryExecutionContext, but they are both separate. Strangely, pushAndExecute cannot ever have more than one element in its continuous_execution_queue_, so I am assuming that it is orphaned code. I also think that no one is using the push functionality of the TEM (which allows multiple trajectories to be executed in a row), and users are waiting for the MGI's move or execute functions to return instead.
Seeing as there is already functionality in TEM to work through a queue of trajectories, extending it appears to be the best option. Instead of executing the trajectories one-by-one, the continuous_execution thread should check if the next trajectory in the queue can be executed safely in parallel to the currently executed ones, and start its asynchronous execution. This requires the executePart, waitForExecution functions to be thread-safe and refer to a specific group, but the default behavior could be compatible with the original API.
My only concern is that the TEM currently does not have a notion of safety, but it would need to be able to check if two robot trajectories collide or not. But it owns a robot_state, so we could add such a function there.

Dear all,
I am working with two real panda robots. I built a MoveIT package for interface with the two panda robots and it works fine in the simulator. Then, I configured the controllers.yaml to act with the real two robots via the combined_panda/effort_joint_trajectory_controller and I can read and visualize the robots state/joints values (/combined_panda/joints) in the Rviz.
I have three planning groups in the moveIT package.
1- panda_1 (panda_1_joint1 … panda_1_joint7)
2- pnada_2 (panda_1_joint1 … panda_2_joint7)
3- combined_panda (panda_1_joint1 … panda_1_joint7 … panda_2_joint1 … panda_2 _joint7)
From rviz, I can control both robots (combined_panda planning group) to reach different/random poses, and it is working fine. But I can not control one robot separately (I can not use ( panda_1 planning group or panda_2 planning group), it gives the following error,
franka_comined_control “ERROR: joints on incoming goal don’t match the controller joints”
So, I run different move_groups on a script:
1- for panda_1
2- for panda_2
and execute the two move_goups as two threads in the script. But it still doesn’t work.
When I worked with the combined group (14 joints → which has the two subgroups (panda_1 and panda_2)), and I set a target pose for every robot (panda_1 and panda_1) and execute them from one planning group by setting the pose target and gripper link of every robot. It give me these error:
‘’ Unable to solve planning problem’’
‘’ More than one constraint is set. If your move_group does not have multiple end effector/arms, this is unusual. and a move_group interface and forgetting to call clearPoseTargets () or equivalent?’’
Can anyone help me in this regard ?

If multiple move groups (robots) are combined under a single move group (let's call it all_groups) such as discussed here, would the following approach work to address the main topic of this thread?

Plan for all_groups which should (?) account for potential collisions between individual robots. I guess it would be the end_effector_link argument of MoveGroupInterface methods like setPoseTarget that determined which robot to plan for while the plan result for the other robots don't matter.
Don't execute the plan but rather replace the remaining trajectory for the joints of the robot that you just planned for by using the trajectory replacement method by directly sending the trajectory to the trajectory controller.

The original topic of the thread was the simultaneous execution of multiple trajectories (of disjoint groups).
This is not supported currently. However, there is a pending PR: https://github.com/moveit/moveit/pull/3243.
The referenced trajectory replacement method will just replace an old trajectory with the new one (with a smooth transition).
This will not help for the original issue.

authors: Erickrk MahmoudSalem92 felixvd gavanderhoorn gbcarlos henningkayser jrgnicho rassom-anatol rhaschke ur10 v4hn

repo: moveit/moveit


text:
PENDING Race condition

Summary

The blockchain service could be stuck in Pending due to how the initiator and counterparty events are processes simultaneously:
If both events are polled at the same time, Pending is returned (source)

Add this PoC in protocol-units/bridge/shared/tests/blockchain_service.rs

#[tokio::test]
async fn test_bridge_poll_stuck() {
    // Initialize the mock blockchain service
    let mut blockchain_service = MockBlockchainService::build();

    // Simulate initiating a bridge transfer
    blockchain_service
        .initiator_contract
        .with_next_bridge_transfer_id("transfer_id")
        .initiate_bridge_transfer(
            InitiatorAddress::from("initiator"),
            RecipientAddress::from("recipient"),
            HashLock("hash_lock"),
            TimeLock(100),
            Amount(1000),
        )
        .await
        .expect("initiate_bridge_transfer failed");

    // Simulate locking assets on the counterparty side
    blockchain_service
        .counterparty_contract
        .lock_bridge_transfer_assets(
            BridgeTransferId("transfer_id2"),
            HashLock("hash_lock2"),
            TimeLock(100),
            InitiatorAddress::from("initiator2"),
            RecipientAddress::from("recipient2"),
            Amount(1000),
        )
        .await
        .expect("lock_bridge_transfer_assets failed");

    // Create a context for polling
    let mut cx = Context::from_waker(futures::task::noop_waker_ref());

    // Poll for the next event
    // This should return a Ready state since we've added events to both initiator and counterparty
    let event = blockchain_service.poll_next_event(&mut cx);

    // Assert that the event is not Pending
    // If this assertion fails, it indicates that the system is stuck in a Pending state
    // even though there are events in the queue.
	// The system might get stuck in a Pending state due to how initiator and counterparty
	// events are processed simultaneously.
	// https://github.com/movementlabsxyz/movement/blob/dd8c8a7a5a946e8071550bf3192176aa99b39fe8/protocol-units/bridge/shared/src/blockchain_service.rs#L45-L58
    assert_ne!(
        event,
        Poll::Pending
    );

    // Print the event for debugging purposes
    println!("{:?}", event);

    // Add another event to the queue to simulate a new bridge transfer to see if another event
	// detection works
    blockchain_service
        .initiator_contract
        .with_next_bridge_transfer_id("transfer_id3")
        .initiate_bridge_transfer(
            InitiatorAddress::from("initiator3"),
            RecipientAddress::from("recipient3"),
            HashLock("hash_lock3"),
            TimeLock(100),
            Amount(1000),
        )
        .await
        .expect("initiate_bridge_transfer failed");

    // Create a new context for polling
    let mut cx = Context::from_waker(futures::task::noop_waker_ref());

    // Poll for the next event again
    let event = blockchain_service.poll_next_event(&mut cx);

    // Assert that the event is not Pending
    // If this assertion fails, it indicates that the system is stuck in a Pending state
    // even though there are events in the queue.
    assert_ne!(
        event,
        Poll::Pending
    );

    // Print the event for debugging purposes
    println!("{:?}", event);
}

Possible Solutions
Event Queuing
Idea: Queue up the events from the initiator and counterparty separately. When an event is detected, enqueue it and process the queue in order, ensuring that events are processed one at a time.
Implementation: Maintain separate queues for initiator and counterparty events, and process each queue in the order events were received.
let mut event_queue: VecDeque<Event> = VecDeque::new();

if let Poll::Ready(event) = blockchain_service.poll_next_event_from_initiator(&mut cx) {
    event_queue.push_back(event);
}

if let Poll::Ready(event) = blockchain_service.poll_next_event_from_counterparty(&mut cx) {
    event_queue.push_back(event);
}

if let Some(event) = event_queue.pop_front() {
    return Poll::Ready(event);
}

Poll::Pending

Atomic State Management
Idea: Use atomic state management to keep track of the state of event processing. For example, you can use an atomic flag to ensure that only one event (from either the initiator or counterparty) is processed at any given time.
Implementation: An atomic flag can be used to track whether the system is currently processing an event. If one event is being processed, other events are temporarily ignored until the first one is completed.
use std::sync::atomic::{AtomicBool, Ordering};

static IS_PROCESSING: AtomicBool = AtomicBool::new(false);

if !IS_PROCESSING.compare_and_swap(false, true, Ordering::SeqCst) {
    match blockchain_service.poll_next_event(&mut cx) {
        Poll::Ready(event) => {
            IS_PROCESSING.store(false, Ordering::SeqCst);
            return Poll::Ready(event);
        }
        Poll::Pending => {
            IS_PROCESSING.store(false, Ordering::SeqCst);
        }
    }
}

First, I'll explain how I understand this code to ensure we're aligned on what needs to be done.
The function poll_next_event in the BlockchainService trait is integrated into a stream of ContractEvent events. Each time the poll_next function is called, it invokes the two poll methods from CounterpartyContractMonitoring and InitiatorContractMonitoring. This implementation returns when either of the two methods returns. The possible cases are:

Both Pending: Returns Poll::Pending, which indicates that no result is available, and the function will be called again by the runtime. The stream doesn't return.
(Ready, Pending): Returns the result of the first as Poll::Ready(Some(first event)). The stream returns Some(first event), and the function is called again to get the next event.
* (Pending, Ready): The stream returns Poll::Ready(Some(second event)).
* Both Ready: Returns the result of the first, and the second result is lost. This case is problematic because the result of calling self.counterparty_monitoring().poll_next_unpin(cx) is discarded.

The proposed solutions don’t address this issue. I don’t fully understand the second solution, but like the first, it only returns one event.
I don't see the issue with returning Poll::Pending. In the test test_bridge_poll_stuck(), we initialize both sources with events. There's no reason to receive a Poll::Pending if the polling method works correctly. If Poll::Pending is returned, it suggests that the polling method of one or both services isn't working as expected because they aren’t returning their events. The test also doesn't verify that all events from both sources are received. Since both sources contain events, we should get all of them. Because the code doesn't handle the (Ready, Ready) case, there's a strong chance that it will fail.

Yes, you're right.
We should handle the (Ready, Ready) case though as that will be a likely case.

To do that, there are 2 possibilities, I think:

Steam Item is a tuple of Option<ContractEvent<_>>. In fact, we return the result of the execution of the 2 methods. It changes the BlockchainService signature and how the event is processed.
We add a new variant of ContractEvent, for example Both(ContractEvent, ContractEvent) when there's 2 result. It changes how the even is processed.

I don't have a real opinion. It seems the second do fewer changes, but I'm not sure as I don't know all the code that process event. Tell which you prefer.

Second choice 🙏

This has been resolved in the new event monitoring implementation.

repo: movementlabsxyz/movement


text:
Inject execution debugging info into query plan

As each step is completed, inject some information into the step that aids in debugging step failures and timing.
The information is accessed on the result object when the below request header is sent: X-Bramble-Debug: plan

Maybe this should be switched on based on timings being provided in the X-Bramble-Debug header

Yeah I considered that but I thought it was a bit unexpected injecting the entire plan when asking for timings.

repo: movio/bramble


text:
PHP Warning with new endpoint format

Warning: Missing argument 2 for Leean\AbstractEndpoint::filter_data(), called in /Applications/MAMP/htdocs/skaled.com-backend/wp-content/plugins/skaled/vendor/moxie-leean/wp-endpoints-static/src/StaticApi.php on line 36

Do we have more info on this?

Yes, look at the code-  it's missing a required param. It should either be optional or we should pass that param.

Right! However the issue should be open on the abstract class instead IMHO since is there where the fix should happen.

Fair enough.

Closing this one here and open the issue on the parent class.

repo: moxie-leean/wp-endpoints-static


text:
🛑 t10n Services: Dynamic Image CDN (Das Quartier) is down

In 3bd51d9, t10n Services: Dynamic Image CDN (Das Quartier) (https://dq-images.t10n.de) was down:

HTTP code: 404
Response time: 214 ms

Resolved: t10n Services: Dynamic Image CDN (Das Quartier) is back up in 2923bae after 12 minutes.

repo: moximoti/upptime


text:
Created documentation for Search Options feature

Fix #243

To clarify, my question was about considering "Search options" as a subtopic of "Search", not to move everything down under Search.

Search and filters
-- Search
--- Options
-- Filters
--- Translation status
--- Extra filters
--- Tags

authors: flodolo harmitgoswami


text:
Remove old jquery-ui rollup

Fixes #1266

r+

authors: muffinresearch tofumatt

repo: mozilla/olympia


text:
Don't try to delete non-exisent theme url (bug 1142449)

Fixes bug 1142449

@clouserw @kmaglione r? I'd like to include this in today's push if possible, if someone can QA it once it's merged.

You've got a typo in the commit message / pull request title :)

It's a good thing the branch name was correct, this way, thanks to a stealth git commit --amend i could camouflage all this... no one will ever know! Oh, wait...

r+ once tests are done and they pass

authors: diox magopian


text:
Getting error while trying to load a pdf file in jsp from local storage.

var url = 'D:/IIV3Project/Documents/Invoices/invoices/invoice.pdf'; PDFJS.getDocument(url) .then(function(pdf) { 	    	var elem = document.getElementById('myCanvas'); 	    	$(".document").on('dblclick',function() { 	    	elem.addEventListener('dblclick', function() { 	    	}, false); 	    	    	        var index = $(this).attr("id"); 	    	    	 }); 	    });
Below is the error i'm getting

The problem, that XMLHttpRequest isn't allowed for file:// URLs, is clearly indicated in your screen-shot of the error messages.
This is not a PDF.js issue, but rather a browser specific issue, and the solution is to use a local server instead. Please note that this browser limitation is mentioned in https://github.com/mozilla/pdf.js#getting-the-code.
Closing as answered/invalid.

Thanks for reply, I need some clarification on this, so as per your answer the above code should work fine with the local file reading. am i correct?

I need some clarification on this, so as per your answer the above code should work fine with the local file reading. am i correct?

No, you are not. Due to your browsers limitation XHR cannot read from local file.

@yurydelendik okay, then how can i read from local storage. pls help.

how can i read from local storage

By design of some browsers you cannot. Please view docs how to read using XMLHttpRequest from local file and what are limitation for your particular browser. You can also find way how to loosen this limitation for your use case. Notice that this question is not related to PDF.js.

Fine, thanks.


text:
Attempt to significantly reduce the number of ChunkedStream.{ensureByte, ensureRange} calls by inlining the this.progressiveDataLength checks at the call-sites

The number of in particular ChunkedStream.ensureByte calls is often absolutely huge (on the order of million calls) when loading and rendering even moderately complicated PDF files, which isn't entirely surprising considering that the getByte/getBytes/peekByte/peekBytes methods are used for essentially all data reading/parsing.
The idea implemented in this patch is to inline an inverted progressiveDataLength check at all of the ensureByte/ensureRange call-sites, which in practice will often result in several orders of magnitude fewer function calls.
Obviously this patch will only help if the browser supports streaming, which all reasonably modern browsers now do (including the Firefox built-in PDF viewer), and assuming that the user didn't set the disableStream option (e.g. for using disableAutoFetch). However, I think we should be able to improve performance for the default out-of-the-box use case, without worrying about e.g. older browsers (where this patch will thus incur one additional check before calling ensureByte/ensureRange).
This patch was inspired by the first commit in PR #5005, which was subsequently backed out in PR #5145 for causing regressions. Since the general idea of avoiding unnecessary function calls was really nice, I figured that re-attempting this in one way or another wouldn't be a bad idea.
Given that streaming is now supported, which it wasn't back then, using progressiveDataLength seemed like an easier approach in general since it also allowed supporting both ensureByte and ensureRange.
This sort of patch obviously needs data to back it up, hence I've benchmarked the changes using the following manifest file (with the default tracemonkey file):
[
    {  "id": "tracemonkey-eq",
       "file": "pdfs/tracemonkey.pdf",
       "md5": "9a192d8b1a7dc652a19835f6f08098bd",
       "rounds": 250,
       "type": "eq"
    }
]

I get the following complete results when comparing this patch against the master branch:
-- Grouped By browser, stat --
browser | stat         | Count | Baseline(ms) | Current(ms) | +/- |    %  | Result(P<.05)
------- | ------------ | ----- | ------------ | ----------- | --- | ----- | -------------
Firefox | Overall      |  3500 |          140 |         134 |  -6 | -4.46 |        faster
Firefox | Page Request |  3500 |            2 |           2 |   0 | -0.10 |
Firefox | Rendering    |  3500 |          138 |         131 |  -6 | -4.54 |        faster

Here it's pretty clear that the patch does have a positive net effect, even for a PDF file of fairly moderate size and complexity. However, in this case it's probably interesting to also look at the results per page:
-- Grouped By page, stat --
page | stat         | Count | Baseline(ms) | Current(ms) | +/- |     %  | Result(P<.05)
---- | ------------ | ----- | ------------ | ----------- | --- | ------ | -------------
0    | Overall      |   250 |           74 |          75 |   1 |   0.69 |
0    | Page Request |   250 |            1 |           1 |   0 |  33.20 |
0    | Rendering    |   250 |           73 |          74 |   0 |   0.25 |
1    | Overall      |   250 |          123 |         121 |  -2 |  -1.87 |        faster
1    | Page Request |   250 |            3 |           2 |   0 | -11.73 |
1    | Rendering    |   250 |          121 |         119 |  -2 |  -1.67 |
2    | Overall      |   250 |           64 |          63 |  -1 |  -1.91 |
2    | Page Request |   250 |            1 |           1 |   0 |   8.81 |
2    | Rendering    |   250 |           63 |          62 |  -1 |  -2.13 |        faster
3    | Overall      |   250 |           97 |          97 |   0 |  -0.06 |
3    | Page Request |   250 |            1 |           1 |   0 |  25.37 |
3    | Rendering    |   250 |           96 |          95 |   0 |  -0.34 |
4    | Overall      |   250 |           97 |          97 |   0 |  -0.38 |
4    | Page Request |   250 |            1 |           1 |   0 |  -5.97 |
4    | Rendering    |   250 |           96 |          96 |   0 |  -0.27 |
5    | Overall      |   250 |           99 |          97 |  -3 |  -2.92 |
5    | Page Request |   250 |            2 |           1 |   0 | -17.20 |
5    | Rendering    |   250 |           98 |          95 |  -3 |  -2.68 |
6    | Overall      |   250 |           99 |          99 |   0 |  -0.14 |
6    | Page Request |   250 |            2 |           2 |   0 | -16.49 |
6    | Rendering    |   250 |           97 |          98 |   0 |   0.16 |
7    | Overall      |   250 |           96 |          95 |  -1 |  -0.55 |
7    | Page Request |   250 |            1 |           2 |   1 |  66.67 |        slower
7    | Rendering    |   250 |           95 |          94 |  -1 |  -1.19 |
8    | Overall      |   250 |           92 |          92 |  -1 |  -0.69 |
8    | Page Request |   250 |            1 |           1 |   0 | -17.60 |
8    | Rendering    |   250 |           91 |          91 |   0 |  -0.52 |
9    | Overall      |   250 |          112 |         112 |   0 |   0.29 |
9    | Page Request |   250 |            2 |           1 |   0 |  -7.92 |
9    | Rendering    |   250 |          110 |         111 |   0 |   0.37 |
10   | Overall      |   250 |          589 |         522 | -67 | -11.38 |        faster
10   | Page Request |   250 |           14 |          13 |   0 |  -1.26 |
10   | Rendering    |   250 |          575 |         508 | -67 | -11.62 |        faster
11   | Overall      |   250 |           66 |          66 |  -1 |  -0.86 |
11   | Page Request |   250 |            1 |           1 |   0 | -16.48 |
11   | Rendering    |   250 |           65 |          65 |   0 |  -0.62 |
12   | Overall      |   250 |          303 |         291 | -12 |  -4.07 |        faster
12   | Page Request |   250 |            2 |           2 |   0 |  12.93 |
12   | Rendering    |   250 |          301 |         289 | -13 |  -4.19 |        faster
13   | Overall      |   250 |           48 |          47 |   0 |  -0.45 |
13   | Page Request |   250 |            1 |           1 |   0 |   1.59 |
13   | Rendering    |   250 |           47 |          46 |   0 |  -0.52 |

Here it's clear that this patch significantly improves the rendering performance of the slowest pages, while not causing any big regressions elsewhere. As expected, this patch thus helps larger and/or more complex pages the most (which is also where even small improvements will be most beneficial).
There's obviously the question if this is slightly regressing simpler pages, but given just how short the times are in most cases it's not inconceivable that the page results above are simply caused be e.g. limited Date.now() and/or limited numerical precision.

/botio test

/botio-linux preview

Nice work, and really good that you revisited the ideas from the original PR!

authors: Snuffleupagus timvandermeij


text:
[fix bug 1138386] Group top menu links

https://bugzilla.mozilla.org/show_bug.cgi?id=1138386

@comzeradd could you please review this?

To avoid wrapping the navigation menu into two lines you could add a padding-left: 0 on #navigation-box. It should be around line 472. That seems to fix the issue.

authors: akatsoulas comzeradd tsmrachel

repo: mozilla/remo


text:
empty group repeat fails

let m = macro {
	rule { { $(case ($x ...)) ... } } => {
		$([$x (,) ...]) (;) ...
	}
}

m {

}

Throws an:
Error: ASSERT: must have a least one non-scalar in repeat

I'm mass closing issues due to the release of 1.0 obviating lots of bugs. If you feel this issue is something we still need to address feel free to reopen.


text:
Project vision to do

Introduction to our project

In wiki/iteration1/project vision

repo: mpeedosk/nupuvere


text:
🛑 DBPERU is down

In fb02ff9, DBPERU (https://www.dbperu.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: DBPERU is back up in cfcc193 after 4 hours, 52 minutes.

repo: mperezdbperu/dbperu


text:
Added support for  in waypoints

This commit adds support for the <desc>-tag in waypoints. These occur e.g. when a loc-file from geocaching.com is converted to gpx via gpsbabel.

Thanks!

authors: kaueraal mpetazzoni

repo: mpetazzoni/leaflet-gpx


text:
Images not rotating after update.

Downloaded the latest version, added those js files (and css files in header):
<script src="js/pannellum.js"></script>
<script src="js/libpannellum.js"></script>

Now the image appears, but can't be rotated. When I use the CDN version, all works fine
<script src="https://cdn.pannellum.org/2.3/pannellum.js"></script>
Note: If libpannellum.js is not added to the project, the plugin won't load pictures at all. It will be stuck on "Loading"

<script type="text/javascript" src="../js/libpannellum.js"></script>
<script type="text/javascript" src="../js/RequestAnimationFrame.js"></script>
<script type="text/javascript" src="../js/pannellum.js"></script>

Get used by the standalone version.
If you want to use it like with the CDN you have to build pannellum first. Check this folder for the build script:
<pannellum-root>/utils/build/build.*
Doing that will create the files like the one from the CDN. That one you can use.

What @DanielBiegler said is correct, although standalone.js is only for the standalone version and shouldn't be added when using the API.
Are there any errors displayed in your browser's developer console?

authors: DanielBiegler Varin6 mpetroff

repo: mpetroff/pannellum


text:
Please include a license

I want to use the code pattern that you have applied but I am frightened to do that as you don't have a license added to your repository which restricts me to do that. Can you please allow everyone to use the code structure as they want It would be so kind of you.
thanks for making it open source

Done: https://github.com/mpetrovich/gherkin-scenario-builder/blob/master/LICENSE

authors: ajaysuwalka mpetrovich

repo: mpetrovich/gherkin-scenario-builder


text:
Enable GHC 8.8.1 windows ci

Since https://github.com/jacobstanley/unix-compat/pull/42 has been closed.
Closes #121

I am getting an error, i think it could be cause i have ghc-8.6.5 as default ghc in $PATH but i am running the tests with ghc-8.8.1:
> cabal test -w ghc-8.8.1
....
 Initial module load (0.79s)
    bios-tests.exe: unable to load package `ghc-prim-0.5.3'
    simple-stack:              bios-tests.exe:  | D:\bin\stack\x86_64-windows\ghc-8.6.5\lib\ghc-prim-0.5.3\HSghc-prim-0.5.3.o: unknown symbol `stg_atomicModifyMutVarzh'

Access violation in generated code when reading 0x30

D:\bin\stack\x86_64-windows\ghc-8.6.5\lib\ghc-prim-0.5.3\HSghc-prim-0.5.3.o
Looks weird.
Well, CI succeeded T_T

I did not execute it locally, so, I am not sure. Previously, CI failed for GHC 8.8.1.

authors: fendor jneira

repo: mpickering/hie-bios


text:
Examples in README

Examples for how to use the nonogram-solver:

encoding a nonogram
generating a nonogram from constrants
generating an optimal nonogram from solutions
solving a nonogram from constraints

If you could create one and find oput how to make one then I could go on and make one too.

repo: mprat/nonogram-solver


text:
refactor(core): replace convert_* wrappers with a member query

Title: refactor(core): replace convert_* wrappers with a member query.

Description:
Replace
https://github.com/mpusz/mp-units/blob/89bafed9619a4a8320046e2be621172a6e88b586/src/core/include/mp-units/framework/customization_points.h#L144-L162
with these members in the quantity-like-traits templates:
  static constexpr bool to_numerical_value_is_explicit = false;
  static constexpr bool from_numerical_value_is_explicit = false;

That removes the need to wrap and unwrap the numbers,
and simplifies the expressions in the explicit specifiers.
This will also require updating

their use in the quantity templates,
the std::chrono support,
their own tests,
any use in the examples, and
the user guide documentation.

Naming is hard 😉:

This does not control the convertibility to/from a numerical value, but to /from quantity/quantity_point. I do not have a good idea of how to rename this, though.

I'm still thinking.

Should we mention "explicit" or "implicit" in the identifier?

Explicit to avoid negations in the explicit specifiers.

Maybe we should be consistent with is_transparent and provide a type instead of the bool value instead?

That just makes the explicit specifiers harder to specify.

Should both flags be true by default and not have to be provided in such case? Or should we always specify them and mandate this in a concept?

I prefer explicitly requiring them.

Maybe:
static constexpr bool to_quantity_is_explicit = false;
static constexpr bool from_quantity_is_explicit = false;

and
static constexpr bool to_quantity_point_is_explicit = false;
static constexpr bool from_quantity_point_is_explicit = false;

?

The problem I have with that is that the "like" parameter is also a quantity (point).

You can also say that those also have some numerical value 😉
I could argue that that others are not "quantities" but duration or MyMetre. Unless it is about the cooperation with Au which uses proper names 😉
So maybe:
static constexpr bool explicit_import = false;
static constexpr bool explicit_export = false;

? Naming is hard 😉

It seems like this was fixed by commit 975025f88a3f58ffc39ca4a4100f40d6a8ca5eff.

authors: JohelEGP mpusz

repo: mpusz/mp-units


text:
[question] Best Practices?

I installed this gem and started casting objects to nil, but I haven't recouped my initial investment yet. I'm concerned about using the gem improperly. Could you share some pointers, pro tips, and/or life hacks to improve my to_nil usage?

The possibilities are endless. Any usage of this gem is a ruby master best practice. Just as an usage example:
begin
  raise StandardError.to_nil
rescue Exception => e
  puts 'owned'
end

You can also use this in rails applications, for example:
# Register nil Mime Type
Mime::Type.register "nil/nil", :nil

respond_to do |format|
  format.xml { render xml: @person.to_xml }
  format.nil { render text: @person.to_nil }
end

Given The Billion Dollar Mistake, this gem is probably worth about tree fiddy.  I ported my apps to Haskell and deleted Ruby.  Thanks anyway.

Hahaha you guys made my day.

authors: carlosbaraza jomo mikegee

license: WTFPL


text:
Following V2 Specification

Judging by your code I can tell pretty quickly that you are more then likely not compliant with the v2 specification of Vector Tiles. I would not rush to update to v2 as there are not any real strict requirements for most processing currently on data being in this format:
https://github.com/mraad/vector-tiles/blob/master/src/main/scala/com/esri/VectorTileLayer.scala#L42
For now I would change things to be simply v1 tiles. I know that the python encoder had similar issues and they rolled back to v1 for now.
Almost everything I listed in their ticket this library does not comply with as well.
If you have any questions about the specification or if you want any review of your encoders/decoders feel free to ask!
/cc @ajturner @mraad

Reverted back to version 1

authors: flippmoke mraad

repo: mraad/vector-tiles