primordic/IssueDupesLite huggingface dataset:
Repository: tldraw/tldraw

Issue #5708: [Bug]: Exported images include unexpected visual artefacts 
Created: 2025-03-20T10:52:32Z
What happened?
Hi,
the image creation looks broken when updating to version 3.10.2, no issues with 3.7.2 and 3.9.0; this is how we are creating the image:
  const { blob } = await editor.toImage([...shapeIds], { format: 'webp', quality : 0.95, scale : 0.3 })
  return blob;

We are copying/pasting an example from the Tldraw website, this one:

This is how the generated image looks like:

To me, it looks like something on your end, but I would be happy to investigate more if you can give any pointers.
Thank you,
Luca
How can we reproduce the bug?
No response
What browsers are you seeing the problem on?
No response
Where did this happen?
The developer package
Contact Details
luca@workera.ai
Code of Conduct

 I agree to follow this project's Code of Conduct

Duplicate issue #5758: [Bug]: When exporting the image, there is a gray border
Created: 2025-03-27T02:28:07Z
What happened?
When exporting the image, there is a gray border.

This happens on  https://tldraw.dev. I was unable to reproduce it in https://tldraw.com
The previously submitted issue：#5737 . Do not arbitrarily close it without confirming that the issue has been resolved.
How can we reproduce the bug?

Visit https://www.tldraw.dev
Create a rectangle shape with some text in it
Go to Export -> PNG

What browsers are you seeing the problem on?
Chrome
Where did this happen?
The tldraw.dev website
Contact Details
No response
Code of Conduct

 I agree to follow this project's Code of Conduct

Closing comment (2025-03-27T17:31:55Z): Ah I see I misunderstood the original bug report! Thanks.
I'm gonna go ahead and arbitrarily close your issue again @docoder but this time because it's a duplicate of #5708.
The working theory is that this is due to CSS from your application affecting the SVG export that's used to generate the image in an unexpected way. If either of you are able to use some of your apps CSS to create a reproduction on https://stackblitz.com/edit/tldraw-template that'd be much appreciated - right now we're not able to reproduce this ourselves.
Repository: tldraw/tldraw

Issue #3860: Add useEditor / editor context information
Created: 2024-06-03T08:25:34Z
Make sure users can find that the useEditor hook needs to be placed inside of the editor context, i.e. as a child of the  component.

Duplicate issue #2629: Extract / improve toasts / dialogs / modals
Created: 2024-01-25T10:19:51Z
Currently all of our toasts, dialogs, translations, and other content lives inside of each editor. This is usually correct—each editor can display messages inside of itself, rather than displaying these on top of the parent container—but it means that an application layer needs to re-implement these features in order to display them outside of the editor. We do this ourselves with certain error messages, migration messages, etc.
Could we extract these providers so that they could be used outside of the editor context?

Closing comment (2024-07-23T14:59:32Z): this feels related to #3860
Repository: tldraw/tldraw

Issue #1567: Loading indicator for pasted images
Created: 2023-06-12T06:52:37Z
What's the feature?
When an image is added to the canvas, we currently show nothing on the canvas while the image loads. This was a prior design decision in the absence of anything better. We don’t know the size of the image or ultimately where it will be placed, so creating a loading state shape for each image was distracting and misleading.
I think we’re now better placed to give some feedback. We can use scoped records to make the indicator(s) don’t sync between users. We can use the svg overlay layer to place indicators at the paste position, even in the case of multiple images being uploaded or added.
Contact Details
No response
Code of Conduct

 I agree to follow this project's Code of Conduct

Duplicate issue #2164: No feedback when uploading an image
Created: 2023-11-07T12:14:13Z
When you add an image, there's a delay where nothing happens

Closing comment (2024-07-22T14:03:30Z): Duplicate of #1567
Repository: tomahawk-player/tomahawk

Issue #452: Player clipping start/end of tracks
Created: 2016-02-23T14:48:28Z
Hi,
i'm really happy with Tomahawk as the scan library / update feature  is perfect for someone with v little time, but i'm having a niggling problem with the player clipping a little from the either/both the start/end of tracks. This doesn't happen in other players and I can't see anything in the player preferences that could be causing it to happen

Duplicate issue #500: Tomahawk cuts of start/end of tracks
Created: 2016-04-25T22:16:25Z
I am pretty sure this is an upstream (vlc) problem but still, maybe we can have some workaround

Closing comment (2016-06-20T05:13:14Z): just noticed this is a duplicate of #452
Repository: tomahawk-player/tomahawk

Issue #443: Albums need to support Local Collection as a metadata/track listing source
Created: 2016-02-18T16:28:43Z
With my Japanese Soundtracks, some Titles are not recognized, despite being loaded into the library.
This screenshot shows the problem (all Files exist locally):

The filename as well as the tags are using roman fonts, not Japanes. For whatever reason, Tomahawk decides to look up the metadata of this album from somewhere else and use the Japanese writing. Following this, the file is not found. If I change the tag to exactly contain the Japanese letters a shown by Tomahawk, the file is found again (e.g. the second entry on my screenshot). If I change the title to Japanese letters, but include the title with roman letters in parentheses alongside, the track is not found (third entry in my screenshot).

Duplicate issue #428: Locally stored albums fail to play "This playlist is currently empty"
Created: 2016-02-05T14:07:36Z
After downloading the app, hooking up bandcamp, soundcloud, google play and my local iTunes collection, I've been having issues both finding albums in search, and more importantly, playing albums directly from my collection.
if I click on an artist, it will show their albums listed correctly, but many of them are randomly missing their cd images. I click play, nothing happens, I click on the album name and am brought to a blank screen with a single track box, no details and the error "This playlist is currently empty" displays on screen.
Issue occurring on Mac OS X

Closing comment (2016-02-22T19:10:49Z): Dupe of #443.
Repository: tomahawk-player/tomahawk

Issue #650: tomahawk-player.org Certificate Expired
Created: 2018-06-26T17:09:51Z
FYI.

Duplicate issue #669: Windows 10 (1909): UAC is completely blocking the installer.
Created: 2020-03-17T19:26:58Z
While launching the installer obtained from the website, this error appears:

Any ideas?

Closing comment (2020-04-02T11:46:21Z): Due to the signing cert being invalid ("Explicity revoked by its issuer"), so I guess technically dupe of #650
Repository: tomahawk-player/tomahawk

Issue #454: Show release Years in Album view 
Created: 2016-02-23T23:33:57Z
On Artist page, etc
This is one of the biggest usability issues for me personally with tomahawk

Duplicate issue #409: No way to see release date in Artists' albums list
Created: 2016-01-22T19:09:07Z

Closing comment (2016-02-28T23:18:50Z): :(
I swear to was trying to find issue about this but failed :(
On Feb 28, 2016 15:17, "Christian Muehlhaeuser" notifications@github.com
wrote:

Dupe of #454 #454 -
even tho older, closing this one.
—
Reply to this email directly or view it on GitHub
#409 (comment)
.
Repository: tomahawk-player/tomahawk

Issue #443: Albums need to support Local Collection as a metadata/track listing source
Created: 2016-02-18T16:28:43Z
With my Japanese Soundtracks, some Titles are not recognized, despite being loaded into the library.
This screenshot shows the problem (all Files exist locally):

The filename as well as the tags are using roman fonts, not Japanes. For whatever reason, Tomahawk decides to look up the metadata of this album from somewhere else and use the Japanese writing. Following this, the file is not found. If I change the tag to exactly contain the Japanese letters a shown by Tomahawk, the file is found again (e.g. the second entry on my screenshot). If I change the title to Japanese letters, but include the title with roman letters in parentheses alongside, the track is not found (third entry in my screenshot).

Duplicate issue #468: album detection is prone to disasters
Created: 2016-03-15T16:18:02Z
examples (all local files, tagged correctly):

bunch of different flac albums detects same track names for all the albums that has nothing common with the actual tracks in the directory and i do not even have tracks named like that anywhere else it seems.
mp3 album collection - discography single artist: shows correct artist and album name in the list, when clicking on the album name you get different album name displayed with different tracks from same artist. several cases of this behavior.

Possibly add ability to easily report wrong detection?

Closing comment (2016-03-15T17:43:49Z): Thanks for the report! This is a dupe of #443. Fix coming up in 0.9 :-)
Repository: tomahawk-player/tomahawk

Issue #432: Hardcoded colors presents usability and aesthetic issues
Created: 2016-02-11T07:57:45Z
On KDE Plasma 5 (linux), if you change the color scheme to something dark, the icons become unreadable. Also, the left-most pane where playlists etc. are shown has a hardcoded color unlike the rest of the app, which looks bad.

Duplicate issue #457: UI problems when using dark xfce skin
Created: 2016-02-28T17:34:02Z
Minor issues:

Back and forward button (top left corner) are too dark
Wrench icon (top right corner) is too dark

Major issues:

"Show more" button below top hits and top albums on artist page doesn't show up at all. This is because my dark skin uses white text. Since the background is hard-coded to white the text should also be hard-coded to grey.

Closing comment (2016-02-28T20:52:56Z): Linked to/Dupe of #432.
Repository: tomahawk-player/tomahawk

Issue #443: Albums need to support Local Collection as a metadata/track listing source
Created: 2016-02-18T16:28:43Z
With my Japanese Soundtracks, some Titles are not recognized, despite being loaded into the library.
This screenshot shows the problem (all Files exist locally):

The filename as well as the tags are using roman fonts, not Japanes. For whatever reason, Tomahawk decides to look up the metadata of this album from somewhere else and use the Japanese writing. Following this, the file is not found. If I change the tag to exactly contain the Japanese letters a shown by Tomahawk, the file is found again (e.g. the second entry on my screenshot). If I change the title to Japanese letters, but include the title with roman letters in parentheses alongside, the track is not found (third entry in my screenshot).

Duplicate issue #360: Tomahawk didn't import all of my MP3 files
Created: 2015-12-11T16:43:43Z
Hello forum,
I recently gave up on iTunes because of their debacle with iCloud Music, which made it so that I can't listen to my purchased and locally stored music without an iCloud Music subscription.  Therefore I went to DoubleTwist, which didn't have great performance, and tried others until landing on Tomahawk, which looks great on the surface.
It imported most of my collection without much issue, but with several album, it didn't import the files at all.  Most of my library has near full ID3 tags and they have at least the Tomahawk minimum.  I have one specific album that refuses to load in Tomahawk even though it has everything including album artwork in the tags.  As you can see by the screenshot below, this DJ Spooky album has totally incorrect data, a bunch of piano music instead of what his album is.  What is going on and how do I fix this?

Please let me know if you need more information.  My music library is about 10200 songs so the log file is a bit huge but I can send it if necessary.

Closing comment (2016-02-22T19:13:39Z): Yes, see the explanation I gave on #443. Closing this as a dupe of #443 - even tho your ticket is older (sorry). Expect a fix in 0.9!
Repository: tomahawk-player/tomahawk

Issue #443: Albums need to support Local Collection as a metadata/track listing source
Created: 2016-02-18T16:28:43Z
With my Japanese Soundtracks, some Titles are not recognized, despite being loaded into the library.
This screenshot shows the problem (all Files exist locally):

The filename as well as the tags are using roman fonts, not Japanes. For whatever reason, Tomahawk decides to look up the metadata of this album from somewhere else and use the Japanese writing. Following this, the file is not found. If I change the tag to exactly contain the Japanese letters a shown by Tomahawk, the file is found again (e.g. the second entry on my screenshot). If I change the title to Japanese letters, but include the title with roman letters in parentheses alongside, the track is not found (third entry in my screenshot).

Duplicate issue #469: Wrong metadata for "Chevelle - Sci-Fi Crimes"
Created: 2016-03-15T19:00:53Z
it is sort of similar to issue #378 but this one is 100% reproducible and is a separate issue.
Tomahawk always, 100% of times shows wrong tracklist for this release.
It shows tracklist from "Sci-Fi Crimes EP"

Closing comment (2016-03-27T16:55:57Z): Dupe of #443.
Repository: tomahawk-player/tomahawk

Issue #443: Albums need to support Local Collection as a metadata/track listing source
Created: 2016-02-18T16:28:43Z
With my Japanese Soundtracks, some Titles are not recognized, despite being loaded into the library.
This screenshot shows the problem (all Files exist locally):

The filename as well as the tags are using roman fonts, not Japanes. For whatever reason, Tomahawk decides to look up the metadata of this album from somewhere else and use the Japanese writing. Following this, the file is not found. If I change the tag to exactly contain the Japanese letters a shown by Tomahawk, the file is found again (e.g. the second entry on my screenshot). If I change the title to Japanese letters, but include the title with roman letters in parentheses alongside, the track is not found (third entry in my screenshot).

Duplicate issue #476: Bad album content shown (Peter Gabriel)
Created: 2016-03-19T00:04:00Z
I recently started using Tomahawk as my music player, and then I realized that even though my music collection is correctly tagged, it's shown incorrectly in Tomahawk.
I discovered that one of my album contains tracks from other album.
I think it's sorta similar to issues #469 and #378
As shown below, Peter Gabriel (Car) contains songs from Peter Gabriel (Melt).

As you can clearly see, exactly same tracks appear here:

This is how Peter Gabriel (Car) tracks are tagged (using Easytag):

I believe everything is fine here, tell me if you see that something is wrong
Tracks from Peter Gabriel (Car) cannot be accessed by searching too.
I can play some of them though, by finding similar tracks on other albums, like here:

When song is played, album name and cover are displayed correctly:

EDIT: Peter Gabriel - Hit (Disc 1) track listing also contains songs from Peter Gabriel (Melt)
My only enabled plugin is Hatchet.
Thank you in advance :)

Closing comment (2016-03-27T16:56:16Z): Dupe of #443.
Repository: tomahawk-player/tomahawk

Issue #495: Resolution
Created: 2016-04-23T01:11:59Z
Hi everyone. I have this problem with the application, I can't maximize it and see each part of it. It's surely caused for my screen resolution (1024x600, I use a mini laptop with Kubuntu 16.04) I have been searching for a good music player, when I finally  found Tomahawk i felt in love but this big little problem... I need a solution 'cause it's the best music player I found. Also, I can only see the play head putting the window at the sides or corners. Sorry for my bad english.

Duplicate issue #518: Program cuts off
Created: 2016-05-29T20:47:32Z
When opening Tomahawk, the bottom of the application (the whole black bar with all the controls, like shuffle, replay, play, pause, etc., are all cut off of my screen. There is now way to re-size so that Tomahawk is vertically smaller, it won't let me. Sometimes it opens correctly, but then, when I click on something, it vertically expands and doesn't let me re-size it back down.
Ubuntu GNOME 15.10
13.3" monitor
Toshiba Satellite

Closing comment (2016-06-02T02:07:43Z): How exactly would i fix that.
On Tue, May 31, 2016 at 1:11 PM, Anton Romanov notifications@github.com
wrote:

this is a duplicate of #495
#495 which is
technically a duplicate of #396
#396 all of this 3
are issues with window size
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#518 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AQgM6RC9YblZj-bgNR68RNR9eyUMD2pbks5qHHndgaJpZM4IpYCT
.
Repository: tomerfiliba-org/rpyc

Issue #503: rpyc_classic.py: No such file or directory (RPyC 5.2.1)
Created: 2022-08-01T08:38:14Z
After installing rpyc 5.2.1 - I see that rpyc_classic.py: No such file or directory
downgrade to 5.1.0 - rpyc_classic.py exists and works good
Environment

rpyc version: rpyc 5.2.1
python version: Python3.8
operating system: QNX 7

Repro: python bin/rpyc_classic.py

Duplicate issue #505: rpyc_classic.py and rpyc_registry.py files no longer in Python Scripts DIR
Created: 2022-08-10T13:58:58Z
Hello, sorry this might be a stupid question/bug report.
In RPyC 5.2.3 I can see the following two executables in the Python Scripts DIR:

In all previous version of RPyC I have used (5.0, 5.1, 4.x) these have always been python (.py) files.
Can I just confirm if this change is expected?
Thanks!

rpyc version: 5.2.3
python version: 3.9.7
operating system: Windows 10

Closing comment (2022-08-10T14:07:27Z): I assume this is likely related to: #503
Repository: tomerfiliba-org/rpyc

Issue #329: rpyc consume cpu on "big" data
Created: 2019-05-29T15:06:57Z
Environment

rpyc version: 4.1.0
Python 3.7.3rc1
Debian GNU/Linux 10

Minimal example
Server:
import rpyc, numpy
from rpyc.utils.server import OneShotServer
rpyc.lib.setup_logger()

big_data = numpy.arange(4 * 64 * 1024 * 1024).tobytes()

class ListService(rpyc.Service):
  def exposed_print(self, data): print(len(data))
  def exposed_get_data(self): return big_data

server = OneShotServer(ListService, port=12345)
server.start()
Client:
import numpy, rpyc
d1 = numpy.arange(4 * 64 * 1024 * 1024).tobytes()
c = rpyc.connect("localhost", 12345)
c.root.print(d1) # CPU stuck
d2 = c.root.get_data() # same behaviour, CPU stuck
but it works fine:
x = rpyc.core.brine.dump(numpy.arange(4 * 64 * 1024 * 1024).tobytes())
passed too:
y = rpyc.core.brine.load(x)

Duplicate issue #323: Very slow pickle on pandas Data Frame
Created: 2019-04-10T10:46:13Z
Hello,
I am trying to write a huge pandas data frame to Hdf5 via server. The data frame is sent from the client.
I figured out that, I should use rpyc.classic.obtain() to unpickle my object before appending it to Hdf5Store. If I don't unpickle, pandas throws an error, as it is netref object.
For smaller data frame, the unpickle is faster, but when the data frame size is huge, it takes a lot of time to unpickle it and append. Is there a work around for this problem ?
Or is there some other method that I should use ? I have attached a minimal example below:
Environment

rpyc 4.0.2
pandas 0.24.2
python 3.7.3
Windows

Minimal example
Server:
import logging
import rpyc

class DummyServer(rpyc.Service):

    def on_connect(self,conn):
        print("Starting Server")
        pass

    def on_disconnect(self,conn):
        pass

    def exposed_write_data(self,dataframe):
        data = pd.HDFStore("Test.h5")
        start = time.time()
        realdata = rpyc.classic.obtain(dataframe)
        end = time.time()
        print(end-start)
        data.append("DATA",realdata)
        print("Writing Data Completed")
        data.close()


if __name__ == "__main__":
    t = ThreadedServer(DummyServer(), port=18860,protocol_config = rpyc.core.protocol.DEFAULT_CONFIG)
    t.start()

Client:
import rpyc
import pandas as pd
rpyc.core.protocol.DEFAULT_CONFIG['allow_pickle'] = True

conn = rpyc.connect("localhost",18860, config=rpyc.core.protocol.DEFAULT_CONFIG)
server = conn.root

import datetime
import pandas as pd
import numpy as np

N = 10000
M = 10000

todays_date = datetime.datetime.now().date()
index = pd.date_range(todays_date-datetime.timedelta(N), periods=N, freq='D')
columns = [str(x) for x in range(M)]
data = np.array([np.arange(N)]*M).T
df = pd.DataFrame(data, index=index, columns=columns)

server.write_data(df)

Closing comment (2019-06-10T04:29:15Z): Thanks for reporting this issue. I've confirmed the issue and it turns out that the issue is a duplicate of #329. Closing this issue (I already started documenting under #329 ).
Repository: tomerfiliba-org/rpyc

Issue #340: More flexible servers
Created: 2019-07-07T23:45:56Z
It's great to see some movement on this project. I imagine that dealing with issues all day gets pretty tiring, since you only ever see problems, but it's great to see this project pick up again.
Right now the server classes aren't very good. The project itself is written to be very flexible, but the servers take a lot away from that since they mean you have to use sockets, not any of the other channel mechanisms.
I'd like to see that recreated to use a mix-in based architecture. That's something I'm hoping to take a crack at over the next few weeks, but my time is limited.
Let's set a milestone for 5.0 with some of the more common pain points, and see what we can do with breaking changes.
Any thoughts on rewriting the server classes?

Duplicate issue #373: Improve message routing and make ZeroDeploy "killer"
Created: 2020-02-23T15:31:32Z
https://mitogen.networkgenomics.com/
Mitogen is "a Python library for writing distributed self-replicating programs". It has a lot of very nice primitives for managing distributed programs, but it's definitely not an RPC system.
Right now rpyc is in this weird space where it's not really good for anything, there's no killer feature. Perhaps easily running your code across a cluster of ssh machines could be that killer feature? Mitogen plus a well-documented multiprocessing-like tool could work very nicely.

Closing comment (2020-02-27T14:15:00Z): Somewhat related to #340 , if we can get the transport working with stdin/stdout, getting it working with mitogen channels should be relatively easy.
Repository: tomerfiliba-org/rpyc

Issue #70: Decorator for exposed function
Created: 2012-03-21T08:03:55Z
Was there a decision to not use decorators for exposing functions?
I feel the decorators are a bit more pythonic and adaptable for subclasses.
def exposed_function_name(self, foo):
    pass
vs
@exposed 
def function_name(self, foo):
    pass
Where the exposed function is like
def exposed(f):
    f._exposed = True
    return f
Then when you check for a functions exposing.
if f.name.startswith('exposed_'):
add a getattr
if f.name.startswith('exposed_') or getattr(f, '_exposed', False):

Duplicate issue #69: Decorator for exposed functions
Created: 2012-03-21T07:48:20Z

Closing comment (2012-03-21T08:18:09Z): Duplicate of #70
Repository: towhee-io/towhee

Issue #355: [Bug]: The pipeline input image does not support png, bmp, gif format “A runtime error will occur”
Created: 2021-12-27T09:17:18Z
Is there an existing issue for this?

 I have searched the existing issues

Current Behavior
pipeline：towhee/image-embedding-efficientnetb5
Using bmp, png, gif format images, the error appears as shown in the figure：



Expected Behavior
No response
Steps To Reproduce
No response
Environment
- Towhee version(e.g. v0.1.3 or 8b23a93):towhee==0.3.1.dev19 
- OS(Ubuntu or CentOS):macos
- CPU/Memory:
- GPU:
- Others:
Anything else?
No response

Duplicate issue #356: [Bug]: Pipeline input images do not support different image types, such as grayscale images
Created: 2021-12-27T10:12:13Z
Is there an existing issue for this?

 I have searched the existing issues

Current Behavior
Grayscale image generation：
import numpy
from PIL import Image
>>> width = 320
>>> height = 240
>>> img_gray= Image.new('L', (width, height))
>>> img_gray.save("img_gray.jpg")

Test script and error log：





Expected Behavior
No response
Steps To Reproduce
No response
Environment
- Towhee version(e.g. v0.1.3 or 8b23a93):0.3.1dev19
- OS(Ubuntu or CentOS):
- CPU/Memory:
- GPU:
- Others:
Anything else?
No response

Closing comment (2021-12-28T09:15:57Z): Potential duplicate: #355
Repository: towhee-io/towhee

Issue #336: [Enhancement]: OperatorLoader error log
Created: 2021-12-23T03:18:44Z
Is there an existing issue for this?

 I have searched the existing issues

What would you like to be added?

Didn't show which operator loader fail, so it's hard to debug.
Why is this needed?
No response
Anything else?
No response

Duplicate issue #347: [Enhancement]: Should be more elegant to handle exceptions
Created: 2021-12-25T08:07:57Z
Is there an existing issue for this?

 I have searched the existing issues

What would you like to be added?
This is not user friendly.
Downloading: "https://download.pytorch.org/models/resnet50-0676ba61.pth" to /Users/ryjiang/.cache/torch/hub/checkpoints/resnet50-0676ba61.pth
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 97.8M/97.8M [00:05<00:00, 18.1MB/s]
Traceback (most recent call last):
  File "index.py", line 9, in <module>
    output = embedding_pipeline('towhee_logo.png')
  File "/usr/local/lib/python3.7/site-packages/towhee/__init__.py", line 73, in __call__
    out_df = self._pipeline(in_df)
  File "/usr/local/lib/python3.7/site-packages/towhee/engine/pipeline.py", line 91, in __call__
    return graph_ctx.result()
  File "/usr/local/lib/python3.7/site-packages/towhee/engine/graph_context.py", line 75, in result
    raise RuntimeError(op.err_msg)
RuntimeError: preprocessing:0 runs failed, error msg: [Errno 2] No such file or directory: 'towhee_logo.png'


Why is this needed?

Prevents program from crashing if an error occurs
Better error message could save a lot of time for developers to debug

Anything else?
No response

Closing comment (2021-12-28T08:56:46Z): Potential duplicate: #336
Repository: towhee-io/towhee

Issue #891: [Bug]: Tried towhee example, found an error"NameError: name 'param_scope' is not defined"
Created: 2022-03-22T11:18:01Z
Is there an existing issue for this?

 I have searched the existing issues

Current Behavior
https://towhee.readthedocs.io/en/main/data_collection/data_collection.html
>>> import towhee
>>> from towhee.functional import DataCollection
>>> class my_add:
...     def __init__(self, val):
...         self.val = val
...     def __call__(self, x):
...         return x+self.val
...
>>> class my_mul:
...     def __init__(self, val):
...         self.val = val
...     def __call__(self, x):
...         return x*self.val
...
>>> with param_scope(dispatcher={
...         'add': my_add, # register `my_add` as `dc.add`
...         'mul': my_mul  # register `my_mul` as `dc.mul`
... }):
...     dc = DataCollection([1,2,3,4])
...     dc.add(1).mul(2).to_list() # call registered operator
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'param_scope' is not defined

Expected Behavior
No response
Steps To Reproduce
No response
Environment
- Towhee version(e.g. v0.1.3 or 8b23a93):0.5.1.dev69
- OS(Ubuntu or CentOS):macos
- CPU/Memory:
- GPU:
- Others:
Anything else?
No response

Duplicate issue #890: [Bug]: Tried towhee example , rasie an error"NameError: name 'Some' is not defined"
Created: 2022-03-22T11:11:00Z
Is there an existing issue for this?

 I have searched the existing issues

Current Behavior
I think the relevant function definition is missing in the case
https://towhee.readthedocs.io/en/main/data_collection/option.html
>>> import towhee
>>> from towhee.functional import DataCollection
>>> a = Some(10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'Some' is not defined
>>> b = Empty()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'Empty' is not defined

Expected Behavior
No response
Steps To Reproduce
No response
Environment
- Towhee version(e.g. v0.1.3 or 8b23a93):0.5.1.dev69
- OS(Ubuntu or CentOS):macos
- CPU/Memory:
- GPU:
- Others:
Anything else?
No response

Closing comment (2022-03-22T11:27:59Z): Duplicate of #891
Repository: towhee-io/towhee

Issue #512: [Bug]: operator dependency not stable
Created: 2022-01-24T09:59:26Z
Is there an existing issue for this?

 I have searched the existing issues

Current Behavior
op_a requires numpy==1.19.5
op_a requires numpy==1.20.1
when running a pipeline that uses both op_a and op_b, towhee will switch NumPy version during pipeline running.
Expected Behavior
NumPy version should be determined by pip. For example:
op_a requires numpy==1.19.5
op_a requires numpy==1.20.1

op_a and op_b are not compatible with each other, for depending on incompatible numpy version.
op_a requires numpy>1.19.5
op_a requires numpy==1.20.1

op_a and op_b are compatible with each other, and pip will install numpy==1.20.1.
Steps To Reproduce
No response
Environment
- Towhee version(e.g. v0.1.3 or 8b23a93):
- OS(Ubuntu or CentOS):
- CPU/Memory:
- GPU:
- Others:
Anything else?
No response

Duplicate issue #513: [Enhancement]: check operator dependency conflics before running the pipeline
Created: 2022-01-25T08:40:09Z
Is there an existing issue for this?

 I have searched the existing issues

What would you like to be added?
check operator dependency before running the pipeline.
pip provides a checker through pip check or python -m pip check.  we can call the checker by import pip
Why is this needed?
No response
Anything else?
No response

Closing comment (2022-01-25T09:05:10Z): /duplicate #512
find a solution, need some coding
Repository: tpope/vim-fugitive

Issue #1963: Large Unpulled section
Created: 2022-04-01T18:45:09Z
I have a problem when working on a branch in active/big repository – Unpulled section is almost always at 256+ commits limit. This makes it hard to work with the status buffer:

Sections I care about – Unstaged/Staged and Unpushed – are separated by huge but mostly useless Unpulled
Visual noise from many commits I don't really care about
I feel loading displaying these commits makes the status buffer slower

Workarounds I can think of:

Merge/rebase w/ upstream often. Not always a good option
Don't fetch often, keep upstream stale. Doesn't work if I work with multiple branches
Unset upstream branch. Removes Unpushed section which is a no-go
Use 'fake' local upstream branch. Needs constant manual effort


Did I miss any existing workaround? If not, what do you think about these ideas:

Reduce limit for Unpulled from 256 to 10 displayed commits
Don't show commits for Unpulled at all
Make these sections foldable, fold Unpulled by default
Make Unpulled hideable through configuration (fugitive or git)

Duplicate issue #1944: Show unpushed commits before unpulled in the fugitive summary
Created: 2022-02-03T23:57:38Z
When working on a local branch which lags behind its remote upstream, the fugitive summary shows unpulled commits before the local unpushed ones.  This makes it a bit less convenient to do fixup, squash and rebase operations from the summary buffer as users need to scroll over the Unpulled section to find target commit.
Can we switch section order and show the Unpushed commits before Unpulled?
The patch here should do just that -
diff --git a/autoload/fugitive.vim b/autoload/fugitive.vim
index fc30676..d99f3f0 100644
--- a/autoload/fugitive.vim
+++ b/autoload/fugitive.vim
@@ -2813,18 +2813,18 @@ function! fugitive#BufReadStatus(...) abort
     call s:AddSection('Staged', staged)
     let staged_end = len(staged) ? line('$') : 0
 
-    if len(pull) && get(props, 'branch.ab') !~# ' -0$'
-      call s:AddLogSection('Unpulled from ' . pull, head, pull)
-    endif
-    if len(push) && push !=# pull
-      call s:AddLogSection('Unpulled from ' . push, head, push)
-    endif
     if len(pull) && push !=# pull
       call s:AddLogSection('Unpushed to ' . pull, pull, head)
     endif
     if len(push) && !(push ==# pull && get(props, 'branch.ab') =~# '^+0 ')
       call s:AddLogSection('Unpushed to ' . push, push, head)
     endif
+    if len(pull) && get(props, 'branch.ab') !~# ' -0$'
+      call s:AddLogSection('Unpulled from ' . pull, head, pull)
+    endif
+    if len(push) && push !=# pull
+      call s:AddLogSection('Unpulled from ' . push, head, push)
+    endif
 
     setlocal nomodified readonly noswapfile
     doautocmd BufReadPost

Closing comment (2022-06-07T19:00:32Z): Duplicate of #1963.  Fixed by cba8634.
Repository: tpope/vim-fugitive

Issue #120: Pressing <CR> on a hash gives "Can't open file" on Windows Vista
Created: 2011-10-23T19:33:52Z
I'm running vim-fugitive cloned on 10/22/2011 with gvim 7.3 (MS-Windows 32-bit GUI version with OLE support, compiled Oct 27 2010 17:59:02) on Windows Vista Home Premium with Service Pack 1.  I have the full install of msysGit-1.7.7-preview20111014 located in AppData\Local\msysgit with the "bin" and "mingw\bin" folders on my PATH.
I renamed my "plugins" folder and moved everything else out of "bundle", so the Vim environment should be pretty "clean" (other than some mappings and a few s: functions in my vimrc).
I open Vim, open a file in my repo and then ":Gedit HEAD".  This gives me the buffer .git\HEAD with "refs: refs/head/master".  Pressing  gives me the buffer .git\refs\heads\master with a SHA1 hash.  So far, so good.  Pressing  again produces this error:
Error detected while processing function 18_BufReadObject..18_ReplaceCmd:
line   14:
E484: Can't open file C:\Users\Brandon\AppData\Local\Temp\VIo9D57.tmp
Please let me know if there is any other information I can provide or steps I can take to troubleshoot this.  I'm also open to any suggestions about a better git setup.  I've been using the cygwin git for command-line usage, but installed msysGit partly so I could try out TortoiseGit (I use TortoiseSVN extensively for SVN-hosted projects, but am trying to shift to git and git-svn) and partly because I gathered that it may perform better than the cygwin version.  Obviously, switching back to Linux would be a help (and believe me, I find more reasons all the time), but work-related requirements demand I maintain a Windows environment, for now.
Thanks!

Duplicate issue #191: Unable to View and browse Git object on windows.
Created: 2012-04-19T15:37:30Z
I am running Git 1.7.4 under windows and using CREAM's build of GVim.
Every time I attempt to open a commit object
:Gedit master
Then press return on the resulting SHA, I get the following error:
Error Detected while processing function <SNR>30_ReplaceCmd:
line 14:
E484 Can't open the file C:\Users\ramiel\AppData\Local\Temp\VIoEFE0.tmp

This severely limits my ability to navigate my repository. Any assistance you can render would be welcome.

Closing comment (2012-04-20T21:31:04Z): Well in that case, I'll close this as a dupe of #120, and continue discussion on #193.
Repository: tpope/vim-fugitive

Issue #234: Error when switching to eclim ProjectTree
Created: 2012-08-06T23:26:07Z
I use the [eclim http://eclim.org/index.html] plugin. When I switch to the ProjectTree split window (with ^-w,^-w) fugitive throws the following error:
Error detected while processing function <SNR>26_Detect..fugitive#buffer..<SNR>26_buffer..<SNR>26_throw:
line    2:
E605: Exception not caught: fugitive: not a git repository: workspace/project/ProjectTree_1

The project directory is actually a git repository, but the ProjectTree_1 file/folder doesn't really exist

Duplicate issue #277: fugitive conflicts with eclim's :ProjectTree command
Created: 2012-12-03T01:25:57Z
If I open project tree using this command in eclim, each time I focus project tree's window this error appears:
Error detected while processing function <SNR>27_Detect..fugitive#buffer..<SNR>27_buffer..<SNR>27_throw:
line    2:
E605: Exception not caught: fugitive: not a git repository: /home/user/workspace/project/ProjectTree_2

:!echo % shows that :ProjectTree's filename is ProjectTree_2, and there is no file /home/user/workspace/project/ProjectTree_2 present.

Closing comment (2012-12-03T01:39:54Z): Looks like a dupe of #234. Please follow up there if it's still an issue with the very latest eclim.
Repository: tpope/vim-fugitive

Issue #21: Pull/Push in background
Created: 2010-10-29T11:30:14Z
Using  :Git pull/push origin master takes away the entire screen for a considerable amount of time. I suggest running pull/push in background and display output when done using quickfix window.

Duplicate issue #22: Pull/Push in background
Created: 2010-10-29T11:30:15Z
Using  :Git pull/push origin master takes away the entire screen for a considerable amount of time. I suggest running pull/push in background and display output when done using quickfix window.

Closing comment (2025-02-22T12:09:11Z): mentioned duplicate: #21
Repository: tpope/vim-fugitive

Issue #1169: Gstatus split above no matter what
Created: 2019-01-11T16:08:59Z
I set set splitbelow in my vimrc file, both :split and :Gsplit respect that. however, :Gstatus still put split window above, no matter what. Even with command line :belowright Gstatus.
any idea what's going wrong?

Duplicate issue #1178: :Gstatus does not respect splitbelow vim option
Created: 2019-01-22T21:16:35Z
:Gstatus command started to split over the current window, disregarding vim splitbelow option.  Also the created window is takes half of vim window size, previously only a fixed size window was taken, which is a much better default.

Closing comment (2019-01-27T11:06:12Z): Duplicate of #1169 (and already fixed)
Repository: tpope/vim-fugitive

Issue #1446: Wall-of-text issue with refreshing git hooks
Created: 2020-01-26T18:59:52Z
Hey 👋,
I'm using https://github.com/typicode/husky for some of my projects and when triggering a hook fugitive outputs a lot of text. I have to press <Space> to go down a full screen more than a couple of times. The text is also blank until I scroll up and down a bit. The following is an example of the output generated:
husky > pre-commit (node v10.18.1)
^[[?25l  ^[[32m✔^[[39m Preparing...
  ^[[33m❯^[[39m Running tasks...
    ^[[33m❯^[[39m Running tasks for *.{js,jsx,ts,tsx}
      ^[[33m⠙^[[39m prettier --write
        eslint --fix
        jest --findRelatedTests
    ^[[33m↓^[[39m Running tasks for *.json ^[[2m[skipped]^[[22m
    ^[[90m  → No staged files match *.json^[[39m
    Applying modifications...
    Cleaning up...

The above text is repeated atleast a 50-100 times (except the first one of course).
Is is possible for fugitive to handle these cases where the git hook is refreshing the output? Or is it possible to fugitive to skip the output?

Duplicate issue #1460: precommit hook show terminal escape characters in output
Created: 2020-02-07T04:25:35Z
I'm using some npm packages for precommit linting (husky and lint-staged).
lint-staged attempts to rewrite characters in place in the terminal by using escape characters, is there anyway i can get the fugitive window that precommit output shows in to either support or drop these escape characters?

Closing comment (2020-02-07T04:28:05Z): Dupe of #1446. Fixed in lint-staged/lint-staged#781.
Repository: tpope/vim-fugitive

Issue #97: Shortcut to checkout/remove files
Created: 2011-08-07T14:13:22Z
It would be great to have an shortcut in Gstatus to quickly restore the working copy for a certain file.
Using co is propably a pretty good shortcut for this. I figured this way:
Anytime you press the desired key combination, the file will be reverted to the current state (HEAD) of the remote repository (if there is one).

Staged file: Unstage + Checkout
Unstaged file: Checkout
Untracked file: Remove from filesystem

I guess a little confirmation message should also be included, especially on removing untracked files.

Duplicate issue #225: Revert unstaged changes on a file from :Gstatus
Created: 2012-07-13T16:56:53Z
Right before I commit, I :Gstatus to see what files I've changed, and stage my changes, so I tend to use the - command there instead of :Gwrite to stage. Often I get to there and find I have local changes I forgot about and don't want to commit: say, debugging output in a file I didn't otherwise modify. So at that point I'd like to be able to revert the changes to that file (as if by git checkout -f -- filename). It would be really convenient to me to be able to do that from a map in the status window. My first suggestion for the map would be r or R, but I'm happy with any letter.
I'm confident I can send a patch for this feature by looking at the code for the - map, but I'm asking here first as per the readme.

Closing comment (2012-07-13T18:24:47Z): Dupe of #97, which contains my initial objections to the idea. I'd recommend subscribing to notifications for that issue, as fresh thought on the problem has just now given me a potential solution.
Repository: tpope/vim-fugitive

Issue #655: Fugitive doesnt seem to understand git workdirs created by 'git checkout --to'
Created: 2015-06-16T11:19:22Z
This command is reasonably new, git v2.4 or v2.4.1.

Duplicate issue #682: Fugitive commands not working in a worktree directory
Created: 2015-08-26T16:27:29Z
If inside a git repo we use the command git worktree to create a different worktree in our file system and go there, then fugitive does not detect the project as using Git.
This directory would contain a file .git with gitdir: /absolute/path/to/git/dir/for/this/worktree.
I don't mind giving this a try, but my VimScript is close to 0.

Closing comment (2015-09-23T18:43:57Z): Also, this seems to be a duplicate of #655.
Repository: tpope/vim-fugitive

Issue #590: Invalid address with a given range in Gbrowse
Created: 2015-01-02T20:30:34Z
If, for instance, I visually select some lines in  fugitive.vim and then run :GBrowse I get
E14: Invalid address

and the browser opens the fugitive.vim file at Github but not at the selected lines.  Note that when no range is given then the command works just fine and no error appears.
I reproduced the error with the following minimal vimrc
set nocompatible
let $ONEDRIVE_HOME = expand('C:/OD/Users/Pedro/')
let $DOTVIM = expand('$ONEDRIVE_HOME/vimfiles')
set runtimepath+=$DOTVIM/bundle/fugitive/

Duplicate issue #597: GBrowse opens file on github but without selected range
Created: 2015-01-21T22:52:33Z
Steps to reproduce

Select a range of lines
:'<,'>Gbrowse

Expected result
Browser opens file on Github with appended range
Actual result
Browser opens file on Github but appended range is missing
Also tried .Gbrowse and :'<,'>.Gbrowse, same result.
This is with fugitive version 2.2 (8971268d91b2bdd12035ceb3319c17c1d69394be) with vim-7.4.560.hg.6462-1.1.x86_64 on openSUSE Factory
Saw this older report that stated that it worked before #148 so might be a regression.
Tried going back to the version before 2012 which is 1.2 but it also doesn't work there. (9521e1cb774e5ae2f2da4e753177b8f962e1febb)
I suppose this could be a bug in vim itself that maybe doesn't pass the range properly to the command ?
Edit: typo

Closing comment (2015-01-21T23:19:50Z): Sounds the same as #590, then.
Repository: tpope/vim-fugitive

Issue #370: Feature request: :Gwrite should accept a range
Created: 2013-08-06T15:04:48Z
I use vim-signify to see signs corresponding to git diff output.  Because of this, I already know where diff hunks exist, and so staging them directly from the buffer with a single command would be great (rather than dropping into a split diff view, :diffput-ing, and closing the diff view).  Allowing :Gwrite to accept a range for its operation would be great; presumably, a higher-order :Ghunkw (or whatever) command could then be cobbled together that used vim-signify signs' line numbers to determine the range to be provided to :Gwrite.

Duplicate issue #514: :Gwrite to take range as an argument
Created: 2014-06-28T18:57:37Z
I use vim-gitgutter which shows me the diff from the index in the buffer itself. It would be great if I could stage a selection with Gwrite inside the buffer itself.
P.S. I know vim-gitgutter allows you to stage hunks but I'd rather stage selections.

Closing comment (2014-06-28T20:51:26Z): Dupe of #370.
Repository: trailofbits/algo

Issue #227: Support for CentOS
Created: 2017-01-30T14:24:44Z
OS / Environment
CentOS 7 - 3.10.0-514.6.1.el7.x86_64 #1 SMP Wed Jan 18 13:06:36 UTC 2017 x86_64
Summary of the problem
I really expect to have possibility to install VPN on CentOS/RHEL as most deployed server distro. What I got is possibility to install only on Ubuntu server - really strange.
Steps to reproduce the behavior
See log part
The way of deployment (cloud or local)
local
Expected behavior
To be able to install on RedHat Like distro
Actual behavior
It offers only Ubuntu server.
Full log
# ./algo 

  What provider would you like to use?
    1. DigitalOcean
    2. Amazon EC2
    3. Google Compute Engine
    4. Microsoft Azure
    5. Install to existing Ubuntu server

Enter the number of your desired provider
: 5

.
.
.

TASK [Install prerequisites] ***************************************************
fatal: [localhost]: FAILED! => {"changed": true, "failed": true, "rc": 1, "stderr": "sudo: apt-get: command not found\n", "stdout": "", "stdout_lines": []}

Duplicate issue #732: Support for CentOS 7
Created: 2017-11-20T07:50:23Z
OS / Environment

CentOS 7
Summary of the problem
It doesn't really work on CentOS 7
Steps to reproduce the behavior
Trying to install it on CentOS 7
The way of deployment (cloud or local)
cloud VPS
Expected behavior
Did anybody figure out how to get it running on CentOS 7?

Closing comment (2017-11-22T09:02:21Z): Duplicate of #227
Repository: trailofbits/algo

Issue #14544: Add Ubuntu support for 22.04 with nftables
Created: 2022-10-21T14:08:51Z
Is your feature request related to a problem? Please describe.
When installing on Ubuntu, Algo does not have any special support for the most recent version. In particular, iptables has been deprecated in favor of nftables.
Describe the solution you'd like
An installation onto Ubuntu 22.04 that uses nftables instead of iptables.
Describe alternatives you've considered
I've looked at adding this support myself but decided it was more than I could handle.
Additional context
No additional context.

Duplicate issue #14515: Support Ubuntu Server 22.04 LTS (Jammy Jellyfish) for Local Installation
Created: 2022-08-24T03:15:54Z
Is your feature request related to a problem? Please describe.

  
    
      algo/docs/deploy-to-ubuntu.md
    
    
         Line 13
      in
      347f864
    
  
  
    

        
          
           Install to existing Ubuntu 18.04 or 20.04 server (for more advanced users) 
        
    
  


The deploy for Local Installation is advertised as working for Ubuntu Server 18.04 and 20.04 but not Ubuntu Server 22.04 for now.
Describe the solution you'd like
Update the Local Installation part of algo to make it working for Ubuntu Server 22.04.

Closing comment (2022-10-30T09:58:29Z): Duplicates #14544
Repository: trailofbits/algo

Issue #196: Webapp that builds Algo VPNs
Created: 2016-12-31T01:03:37Z
Form fields for all the info we need, click create, it spits out the configs at you and downloads and tells you the server info.
Like this: https://www.tinfoilsecurity.com/vpn/new

Duplicate issue #14363: Admin Panel / Web Panel
Created: 2021-11-25T06:57:09Z
Is your feature request related to a problem? Please describe.
It would be great, if there would be an Admin Panel for easy editing configuration/adding Users and routes.
Describe the solution you'd like
A Web Admin Panel like wg Admin Gui would be really great.

Closing comment (2021-12-13T21:50:39Z): Duplicate #196
Repository: treeverse/lakeFS

Issue #3245: Support GC on non-S3 backing stores
Created: 2022-04-20T16:27:12Z

Duplicate issue #3271: Support Garbage Collection on Azure 
Created: 2022-04-28T07:48:23Z
Currently, lakeFS' GC capability is only supported on S3.
This issue is to add support for lakeFS installations that use Azure as their underlying object store.

Closing comment (2022-06-19T14:22:47Z): Related to #3245