text:
Abstract display interface

hello,
How would I go about integrating a new display into the code base, a Noritake-Itron GU240x64D-K612A8 which is a graphical unit and can be communicated with over a parallel interface, RS232, SPI and I2C. As it happens I would prefer the SPI as it would provide more bandwidth. My questions:

what is the abstract interface a driver needs to implement in order to be usable by the higher software layers?
how is the communications interface separated from the semantic interface to the driver?

I have already written a C-version of the low level driver for LCDproc some 10 years ago. I would be happy to convert that to python as long as it works over SPI.
Cheers, peter.

In simple terms, anything that can accept a PIL Image object and render it works.
FYI, the current version of pydPiper is not being actively maintained as I am moving the code-base to Python3 and making some major changes to the architecture.  The work is fairly well along but given my general lack of time for coding these days it is probably going to be spring before I get to a release.  In the new version, all of the display logic has been moved to the Luma.OLED project.  You might want to check that out to see what work would need to be done.

Cheers, yes I saw in another thread that you are in the process of porting to python3 and using Luma. That sounds quite promising.
That being said, if there was a Luma.VFD which supported Noritake VFDs, or others, that would be great. I would be happy to contribute there. Nevertheless, there would need to be a common abstract interface to talk to an abstract LCF/OLED/VFD, at the right kind of granularity. Apart from opening and closing a device, setting up the comms (SPI, I2C, etc), would pydpiper then only send images or updates to images to the underlying driver, or exploit some advanced features of some devices which may not be available on all of them, e.g. the availability of fonts, or other primitives?

I'm going to close this thread as I believe it has mostly moved over to the Luma.(core, lcd, oled) project.  A couple of quick points though.  pydPiper and to a great extend Luma are mainly about rendering bitmaps.  Any fonts, or graphical primitives like lines, rectangles, circles, etc. can be produced using the Pillow library and then sent to the display as a PIL Image.  Unique features (especially fonts) supported by a display are not used though.   Luma does include reproductions of some fonts but this is entirely external to the displays functionality.  Even when using the character interface in luma.core, it is still just rending the text content into a PIL Image and then sending that to the display.

Hello, indeed, with the device specifics in the new version being moved to Luma the support for a Noritake VFD will move there, too. Thanks for your time and consideration.
As for interfaces and the various levels of abstraction in the pydpiper stack, and to recapitulate in my own words, I would imagine that pydpiper interfaces to the music player on one side, retrieving tags as defined in pages; it then sequences these pages, their canvas and widgets. For every page pydpiper creates a rendered image using the Pillow library; the image is then handed over to the Luma device driver to be communicated to the device using an appropriate comms protocol.

Here's the basic application architecture.

Note: pydPiper does not request specific data that it needs from MPD.  MPD sends what it's going to send.  It is up to the pageFile designer to determine what variables will be available from the source (or sources) and design the pages (e.g. screens) accordingly.

Thanks again for the nice diagram. So I presume that:

pyAttention is agnostic to the concrete metadata tags, but just presents them in a dictionary message, independently of the source (which could be some UDP message of some sort). That's the pyAttention output interface;
tinyDisplay needs to marry up the dict message and the pagefile, i.e. needs to make sure that all tags referenced in the pageFile can be populated with the data in pyAttention as data trickle in. If the pageFile is made for a specific player in mind that would be the case one would hope.

Yes, that's mainly correct. One feature I'm not sure was clear though is pyAttention will allow multiple sources to be monitored at the same time.  It provides a single interface to receive data from those multiple sources.  To differentiate those sources, the dictionary it provides back will include a dictionary key (in the diagram this key is 'mpd') to inform the receiving system which source the data is coming from.  It is possible that multiple subsystems could be reported in a single message.
I'm also considering adding a transformation capability to pyAttention to allow you to include in your pageFile (or another config file) a set of rules to use to transform received data.  This could allow you to convert variable types like string to integer, or to trigger more complex processing rules like querying a database.  Let me know if you think this would be useful and what features you think it should include if yes.

Thanks for sharing your thoughts on the new architecture; the idea of merging information streams from various sources is indeed interesting, but certainly challenging. As you rightly say, a problem only arises if the same piece of information is available from more than one source.
I could not help but to think of the initial statement in the repo Readme.md: "A python program written for the Raspberry Pi that controls small LCD and OLED screens for music distributions" . Therefore, my assumption is that pydpiper would be listening to only one music player at a time, but perhaps additional but different kinds of sources.
How a situation would have handled, where different sources produce the same kind of information, but perhaps in different format or units, I would have thought that triaging the data:

is not the responsibility of the pageFile which is a consumer. It manages the layout of metadata defined by tags on widgets and canvasas suitable for a given display and its size. Would these tags be player-agnostic or player-specific? Or would tags be things like source::tag?
is perhaps not the responsibility of pyAttention which acts as an abstraction layer to being a client to different music players and their protocol. Also, like a funnel It merges different input streams into one stream as a two-tiered dictionary and is perhaps agnostic to the tags; just passing on information.
would perhaps be in realm of tinyDisplay. If it finds the same tag in different sources, it would have a rule to deal with it (from a config file)? If pydpiper is primarily a music player display driver, then perhaps all player tags have priority? Would it strip the source and create unitfied tags?

Thinking about how the stream of tags is managed prompts a lot of design decisions.

Currently pydPiper attempts to make the tags player agnostic but this has proven difficult.  I was leaning towards having the next version make the tags player specific in the sense that it would not attempt to normalize the data.  This would mean that each pageFile would then need to be developed to match a particular source.
Perhaps as you suggest it would be better to normalize the data into a defined format like ID3.  If I went this direction, I believe that functionality would live inside the pydPiper code-base as it is the only project that is dedicated to music.  I would want it configuration driven to make it easier to adjust when the distributions invariably modify the information they are sending.
Also, while not impossible to have more than one music source, this is not done in practice.  The multiple sources are normally unrelated to each other.  Typical sources include:

Music metadata (MPD, Volumio or other)
System information (disk space, temperature, ip address)
Weather

This basically means that there is normally no need to decide between two sources when resolving a particular piece of information.

Hello, this sounds all quite reassuring, in particular with regards to the consolidation of information from different sources. In general, it would be preferable if the code could be tag agnostics and tags only live in configuration files such as the pageFile or other; all is data driven.
I kept thinking of the different abstractions and a functional block diagram showing the data flow, e.g. involving:

some kind of player_data_adapter base class with output interface, e.g. time-stamped dictionary,
for every music player that is supported a derived XYZ_data_adapter that listens to the player specific topics on whatever interface, port for protocol the player produces information in,
for every other data source there is a dedicated XYZ_data_adapter for system information, weather or stock exchange, ..
pyAttention is the funnel that instantiates the data adapters needed as configured, or perhaps derived by collecting all tags referenced by the pageFile, e.g. a tag could be mpd::artist in a device specific file pages_Noritake_GU600.py. The output of all data_adapters is then the compilation into two-tier tags dictionary from these sources.
alternatively, the source is not specified in the pageFile, but normalized tags are being used there, such as ID3v2.x tags for music metadata. Then the tag translation needs to happen in the XYZ_data_adapter`, either in code or by using a configuration file defining the map, and only if the tag differs from a standard.

Well, these were just my thoughts on that and perhaps it is useful to you.

@dhrone while you are working on the new python 3 version of pydpiper, I have been trying to build my own python3 based volumio2 client & VFD controller: https://github.com/PeterWurmsdobler/volumio-vfd . It is loosely based on some pydpiper code and does work, albeit not as general as pydpiper, and it has the principal concepts of:

VolumioClient class as a thread producing a PlayerStatus objects into a queue,
main loop taking items of the queue and feeding an abstract CharacterDisplay,
CharacterDisplay base class ingesting PlayerStatus objects,
CharacterDisplayNoritake adapter for the Noritake VFD.

I am looking forward to hearing your feedback.
Cheers, peter.

Nice clean code.  Overall, the design looks good for what it appears you are trying to achieve.  I do have one small suggestion for improvement.
You are re-querying the Volumio service every 1/2 second which seems excessive.  Volumio is very good at sending out a message every time it changes state making the polling style connection you have implemented unnecessary.  If the reason for the frequency is to update the elapsed variable, I'd suggest capturing the current time each time you receive an update and then calculating elapsed during your update_status method.
FYI, the rendering portion of my rewrite is basically done.  That project is tinyDisplay.  If you wanted to leverage the graphical capabilities of your display, it would be pretty simply to add that capability using it.

Thanks for you comments; the polling is a bit naughty and was a quick and expedient way to get the elapsed field updated as you rightly noticed. I have changed that to as you suggested calculating the elapsed time from the last status' elapsed time and the elapsed time since.
I'll have a look at the tinyDisplay and try to understand what would be necessary to integrate the VFD, with or without Luma. I actually cross posted the previous message on https://github.com/rm-hull/luma.core/issues/236#issuecomment-798452928 as I see the need to separate the device command interface and the device Luma adapter.
Cheers, peter.

If you can get luma to fully support your display, integration with tinyDisplay should be straight forward.  tinyDisplay outputs a PIL Image which most luma devices can directly consume.

It would be nice to have VFD support integrated into Luma, which would mean adding an adapter layer with some code is needed to convert the PIL image into a sequence of GU600 calls. It is however not very clear to me

what interface a class representing a new VFD has to implement in order to work with Luma,
what repository it would belong to as there is no provision for VFDs.
Of course, I would like to make some optimisation to not always send the whole image but only areas that have changed. Perhaps there is even some support in PIL to do a diff(image1, image2) -> list.
Cheers, peter.

Developing the adapter layer looks pretty straight forward.  Your display supports a Graphic Write command that seems like what you'll need.  You just need to transform the image into a sequence of pixel values (using getdata()) and then convert into values needed by the Graphic Write command.  Take a look at the ss1106 class to get a sense for how the develop the driver.
As far as where to place it within Luma's projects, I'd recommend within Luma.oled.  While technically the VFD style device is not an OLED it is not that different and I don't think it would be worth spinning up another sub-project just to handle this display type.

Thanks for the hint; I had a look at the device. It is perhaps not too complicated after all. There are only two worries I had or have:

the image format is not clear to me, possibly RGB with 3 bytes per pixel, or one byte per pixel, or monochrome image with one byte for 8 pixels, etc. Eventually, I need to convert 8 pixels into a byte for 8 subsequent pixels for the GU600.
the Luma command/data interface is not clear to me, does it take arrays of uint32, unsigned char , etc. The method name .data() implies a getter, or does it mean .send(), possibly, looking at the code.  IMHO methods should be verbs.

Initially I thought I would add an adapter layer to Luma and use my full driver from my own repo. But probably, it would be too complicated to add a dependency of a Luma.VFD device. So I will just copy & paste the lines needed.

I'm not clear on what you are asking in regards to image format.  Are you trying to understand how the PIL.Image represents its data or how what needs to be sent to the display.
For your second question, the method names are derived from how many displays work.  Typically you either send a .command() to configure the display (move the cursor, clear the display, etc) or you send .data() to be rendered on the display.  Both .command() and .data() take bytes (e.g. uint8 or unsigned char).
There is a small difference between the calls.  .command() accepts the bytes as a list of arguments while .data() takes them as an iterable of bytes (e.g. list, tuple)
.command(cmd, cmd, cmd, ...)
.data([data, data, data])

Many thanks for your response.
As for the first one, it is more the the former, i.e. how PIL.Image represents its data, or more precisely, how to iterate over pixels and the data type of each pixel. Once I know that, I can work out what I need to send to the VFD.
As for the second, I have found by digging more into the code that the expected data type is assumed to be 8-bit quantity, even though in python it is simply an int. It is, however, a limiting assumption by Luma to assume that commands are singly "bytes". Also, what does not help in the interface is the semantics of the method names that sound more like properties,e.g. data().
With respect to the SPI I need to figure out which underlying SPI driver Luma users actually use; the interface stipulates and open and writebytes method; the library I was using, spidev, from https://github.com/doceme/py-spidev.git , does actually consume int of which one byte is bitten off in the c-driver: (__u8)PyInt_AS_LONG(val);
Gradually I am thinking: I should have written all in C++ with clear types.

authors: PeterWurmsdobler dhrone

repo: dhrone/pydPiper


text:
Cherrypick last fixes from gh-pages to master

This is the cherrypick required in #11 and #12.
Fix 404 on null (3bab92e - a317ea8)
The qualifyURL script was setting the img.src to null, causing a 404 error.
A better approach is to use the window.location.href to get the base url and concat it with the relative one.
Show a full-width graph in visualize (4d3652f - 9333b75)
A large application topology causes the nodes that represent some of the components to end up outside the image canvas. This edit shows a full-width graph in the Visualize tab. This will put the table after the graph instead of aside, allowing to display a larger and more relaxed topology to improve the readability.
Note that this feature doesn't fix the bug: a very large topology will still causes the nodes to end up outside the canvas, even at full with. A possible fix could be to take the size passed to the createGraph function as max width and drow nodes inside that space. Then, by setting the svg width equal to the width used by the elements that it contains, you can obtain a smaller canvas with the table aside when possible, and a full-width canvas otherwise.

Thanks @daquinoaldo

source: gharchive/pull-request

authors: daquinoaldo jsoldani

repo: di-unipi-socc/barrel

license_type: permissive

license_source: github-api


text:
Bits & Pieces

Things that should be added somewhere:

https://twitter.com/FriendlyTester/status/1004720793304162304
https://twitter.com/charrett/status/1014042006383779840
https://blog.usejournal.com/what-is-exploratory-testing-the-programmer-edition-881765411f2c
https://thelifeofoneman.com/what-does-a-tester-do

Closed as dup of #20

source: gharchive/issue

repo: dialex/start-testing


text:
Dynamic Variable Callbacks for Runtime Evaluation in Editor

Is your feature request related to a problem? Please describe.
I'm always frustrated when I have to manually add or update numerous game variables directly within the editor for scenarios like checking if a specific mission is completed or if a hero meets certain attribute thresholds. This becomes cumbersome and error-prone, especially when multiple variables need to be updated frequently based on game state changes.
Describe the solution you'd like
I propose the integration of dynamic variable callbacks into the editor. This would allow developers to register a callback function that determines the value of a variable at runtime based on the game's current state or other conditions.
Describe alternatives you've considered
One alternative I considered was using the existing set_variable method to manually update each variable as required. However, this method is suboptimal because it involves updating each variable individually each time there's a change in the game state, which is not only inefficient but also prone to errors.
Additional context
The code I added in "addons/dialogic/Modules/Variable/subsystem_variables.gd" allows for a callback to be registered that checks certain conditions and updates the variable value accordingly:
var dynamic_variable_callback: Callable

func set_variable(variable_path):
   # ...
    if dynamic_variable_callback and dynamic_variable_callback.is_valid():
        value = dynamic_variable_callback.call(variable_path)
        if value != null:
            return value
   #...

This implementation helps streamline variable management, although it currently lacks the ability to test effectively in the editor,
This structure should effectively communicate your feature request and the rationale behind it, helping the development team understand the value of this proposed feature.

Hey @angedelamort, this is an interesting idea.
For dynamic checks, I would usually just suggest calling autoload methods instead. E.g. if you had a Missions autoload like this:
extends Node

enum Status {NOT_STARTED, IN_PROGRESS, DONE}

func mission_status(mission_name: String) -> int:
    # determine status:
    return status

And then in dialogic you can simply go {Missions.mission_status("my_mission")} == Missions.Status.DONE or something like that.
I would actually just consider allowing variables to be expressions, so a variable could be a complex expression in itself, like a call to an autoload method.

That's an interesting Idea using autoload methods. I wasn't sure to understand the doc.
From the documentation, I'm not sure how this would be done. You just use the autoload and expose a function and Dialogic will check for the string and call the method after the "." directly?
I will see if that works well in my C# environment.
By the way, I coded my own dialogue system and I needed some UI and so I started to look around and found what you guys did. I was very impressed. Very similar to what I've done, but way more features and UI lol. Really impressive work. Thanks for sharing.

The docs could probably be better for sure (they always can 😭).
Whatever is in {curly brackets} will be handled by multiple systems. Dialogic will first assume it's a dialogic variable, but if not, it will be passed to the Expression subsystem, which will use Godot's Expression class, with the autoloads passed in as objects. This allows quite a lot of script functionality to be used automatically.
I'm not personally using C# so that is a bit untested, but I don't see a reason why it shouldn't work tbh.
Glad you are enjoying Dialogic so far :)!

This works great! The return signature is even a Variant, so it will do the trick perfectly!
for C#, the annoying part is that I have to create a C# interface to simplify the use in my code.
For example, you want to use the += notation instead of the Connect or having to call dialogicHandler.Call("start", timelinePath); doesn't make it elegant either. If you're interested of creating such an interface, I'll be happy to share some of my code. But that's mainly boiler plate.

Yeah we had a C# wrapper at some point, but because none of the core-maintainers used C# much, it kept being out of date, so for the alpha period it's not planned, maybe once we get into beta, whenever that might happen 🙈
Thank you for the offer though, feel free to contribute, but if you want to do so, chat with us on emilios discord first!

authors: Jowan-Spooner angedelamort

repo: dialogic-godot/dialogic

license: MIT


text:
feat: fit sklearn model on new data if its not provided

Description
Put in place the infrastructure to fir the OOD detector on new data (new scrapes) if an sklearn model is not already provided.

Can you fix tests and black @jerpint ?

current error:
Downloading: 100%|██████████| 440M/440M [00:06<00:00, 71.8MB/s]
INFO:transformers.file_utils:storing https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-uncased-pytorch_model.bin in cache at /root/.cache/torch/transformers/aa1ef1aede4482d0dbcd4d52baad8ae300e60902e88fcb0bebdec09afd232066.36ca03ab34a1a5d5fa7bc3d03d55c4fa650fed07220e2eeebc06ce58d0e9a157
INFO:transformers.file_utils:creating metadata file for /root/.cache/torch/transformers/aa1ef1aede4482d0dbcd4d52baad8ae300e60902e88fcb0bebdec09afd232066.36ca03ab34a1a5d5fa7bc3d03d55c4fa650fed07220e2eeebc06ce58d0e9a157
INFO:filelock:Lock 140603464930384 released on /root/.cache/torch/transformers/aa1ef1aede4482d0dbcd4d52baad8ae300e60902e88fcb0bebdec09afd232066.36ca03ab34a1a5d5fa7bc3d03d55c4fa650fed07220e2eeebc06ce58d0e9a157.lock
INFO:transformers.modeling_utils:loading weights file https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-uncased-pytorch_model.bin from cache at /root/.cache/torch/transformers/aa1ef1aede4482d0dbcd4d52baad8ae300e60902e88fcb0bebdec09afd232066.36ca03ab34a1a5d5fa7bc3d03d55c4fa650fed07220e2eeebc06ce58d0e9a157
INFO:bert_reranker.utils.hp_utils:	hp "dropout" => "0.1"
INFO:bert_reranker.utils.hp_utils:	hp "layers_post_pooling" => "[]"
INFO:bert_reranker.utils.hp_utils:	hp "layers_pre_pooling" => "[]"
INFO:bert_reranker.utils.hp_utils:	hp "normalize_model_result" => "False"
INFO:bert_reranker.utils.hp_utils:	hp "pooling_type" => "avg"
INFO:bert_reranker.models.bert_encoder:setting bert dropout to 0.1
INFO:bert_reranker.utils.hp_utils:	hp "bert_base" => "bert-base-uncased"
INFO:bert_reranker.utils.hp_utils:	hp "dropout_bert" => "0.1"
INFO:bert_reranker.utils.hp_utils:	hp "freeze_bert" => "False"
INFO:bert_reranker.utils.hp_utils:	hp "dropout" => "0.1"
INFO:bert_reranker.utils.hp_utils:	hp "layers_post_pooling" => "[]"
INFO:bert_reranker.utils.hp_utils:	hp "layers_pre_pooling" => "[]"
INFO:bert_reranker.utils.hp_utils:	hp "normalize_model_result" => "False"
INFO:bert_reranker.utils.hp_utils:	hp "pooling_type" => "avg"
INFO:bert_reranker.models.bert_encoder:setting bert dropout to 0.1
2020-06-17 14:38.42 Fitting the sklearn OOD model on the latest data...
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/starlette/routing.py", line 517, in lifespan
    await self.startup()
  File "/usr/local/lib/python3.7/site-packages/starlette/routing.py", line 496, in startup
    handler()
  File "/app/covidfaq/main.py", line 29, in on_startup
    BertPlusOOD()
  File "/app/covidfaq/evaluating/model/bert_plus_ood.py", line 62, in __init__
    BertPlusOOD.instance = BertPlusOOD.__BertPlusOOD()
  File "/app/covidfaq/evaluating/model/bert_plus_ood.py", line 19, in __init__
    "covidfaq/bert_en_model/config.yaml"
  File "/app/covidfaq/evaluating/model/embedding_based_reranker_plus_ood_detector.py", line 71, in __init__
    self.outlier_detector_model = fit_OOD_detector(self.ret_trainee, hyper_params)
  File "/app/covidfaq/evaluating/model/embedding_based_reranker_plus_ood_detector.py", line 25, in fit_OOD_detector
    from bert_reranker.models.sklearn_outliers_model import fit_sklearn_model
ImportError: cannot import name 'fit_sklearn_model' from 'bert_reranker.models.sklearn_outliers_model' (/usr/local/lib/python3.7/site-packages/bert_reranker/models/sklearn_outliers_model.py)

@lp-noel this is expected, because bert_reranker on pypi is not up to date (I would prefer a release once we confirm everything is working as opposed to debugging through releases). Is it possible using poetry to install a pip package from the bert_reranker github repo?
Also, there will be a few paths to change to make this work 100%

@lp-noel this is expected, because bert_reranker on pypi is not up to date (I would prefer a release once we confirm everything is working as opposed to debugging through releases). Is it possible using poetry to install a pip package from the bert_reranker github repo?
Also, there will be a few paths to change to make this work 100%

Probably, but I never did it.
Please change the paths that need to be changed.

Some of the files need to be moved around on your s3 bucket, i will ping you on slack to follow up on this

works locally on MacOS, doesn't work on Linux or in CCI. To investigate.

authors: jerpint lp-noel

repo: dialoguemd/covidfaq


text:
完全按照readme文档部署集群，一直报错

如下三台机器：
192.168.145.61
192.168.145.62
192.168.145.63
部署版本：
3.0
每台机器包含如下配置文件：
client.xml
datasources.xml
客户端路由配置：
<?xml version="1.0" encoding="utf-8"?>
<router-config backup-server="192.168.145.61" backup-server-port="2280">
   <default-server id="192.168.145.61" weight="1.0" port="2280" enable="false"/>
   <default-server id="192.168.145.62" weight="1.0" port="2280" enable="true"/>
   <default-server id="192.168.145.63" weight="1.0" port="2280" enable="true"/>
   <network-policy id="default" title="default" block="false" server-group="default_group">
   </network-policy>
   <server-group id="default_group" title="default-group">
      <group-server id="192.168.145.62"/>
      <group-server id="192.168.145.63"/>
   </server-group>
   <domain id="cat">
      <group id="default">
         <server id="192.168.145.62" port="2280" weight="1.0"/>
         <server id="192.168.145.63" port="2280" weight="1.0"/>
      </group>
   </domain>
</router-config>

服务端配置：
<?xml version="1.0" encoding="utf-8"?>
<server-config>
   <server id="default">
      <properties>
         <property name="local-mode" value="false"/>
         <property name="job-machine" value="false"/>
         <property name="send-machine" value="false"/>
         <property name="alarm-machine" value="false"/>
         <property name="hdfs-enabled" value="false"/>
         <property name="remote-servers" value="192.168.145.61:8080,192.168.145.62:8080,192.168.145.63:8080"/>
      </properties>
      <storage local-base-dir="target/bucket" max-hdfs-storage-time="15" local-report-storage-time="3" local-logivew-storage-time="7" har-mode="true" upload-thread="5">
      </storage>
      <consumer>
         <long-config default-url-threshold="1000" default-sql-threshold="100" default-service-threshold="50">
            <domain name="cat" url-threshold="500" sql-threshold="500"/>
            <domain name="OpenPlatformWeb" url-threshold="100" sql-threshold="500"/>
         </long-config>
      </consumer>
   </server>
   <server id="192.168.145.61">
      <properties>
         <property name="job-machine" value="true"/>
         <property name="send-machine" value="true"/>
         <property name="alarm-machine" value="true"/>
      </properties>
   </server>

现状：
每台机器都可以打开 cat页面，都报错 “出问题CAT的服务端:[192.168.145.63, 192.168.145.62]”
错误信息：
CAT client was disabled due to no CAT servers configured!
然后我把每台机器都放了一个client.xml 这个错误解决了，但是页面还是显示
“出问题CAT的服务端:[192.168.145.63, 192.168.145.62]”
最后说一下，readme 写的真的烂

要不你来写个吧，你牛逼~

我配的要是不对，你给我怼回来就好了，骂我我也接受，而且我觉得文档写的的确有问题，犯不着回我这么句话，等我 commit  -。-
不是一个人说有问题了，，，
#1268
#1026
#989
#855

要不你来写个吧，你牛逼~

我配的要是不对，你给我怼回来就好了，骂我我也接受，而且我觉得文档写的的确有问题，犯不着回我这么句话，等我 commit -。-
而且不是一个人说有问题了
#1268
#1026
#989
#855

你看到所有的issue都是2015以及2016年的issue

其中一个近期也做了详细的回复
也别commit了，这么烂的东西不值得有劳大神。

你看到所有的issue一共四个，三个是2015以及2016年的issue

其中一个近期也做了详细的回复
也别commit了，这么烂的东西不值得有劳大神。
我从没说过cat写得烂，您别和我较劲了，是我用词不当，我删了，向您道歉，对不起！！！但我依旧认为它不够清晰。

repo: dianping/cat

license_source: bigquery


text:
Project description does not display properly on PyPI

Looking at the PyPI page for our initial prerelease, the description is all messed up - it displays in raw Markdown rather than being properly formatted. That needs to be fixed.

FWIW I know I've seen something that is supposed to check the description for validity, although I don't remember what it is. If we can figure that out, it would probably be good to add it as a check during CI or whatever makes sense.

Possibly related: https://packaging.python.org/en/latest/guides/making-a-pypi-friendly-readme/

repo: diazona/setuptools-pyproject-migration


text:
quiz example

add a quiz example to guide.  description exists but add a chapter source course.  also add a template to the guide that the users can download and start with.

This is done.

repo: diderot-edu/diderot-guide

license: Unlicense


text:
现在支持静态js引入么，没有找到logic-flow.js源码

现在支持静态js引入么，没有找到logic-flow.js源码

https://github.com/didi/LogicFlow/issues/179

repo: didi/LogicFlow


text:
java.lang.ClassCastException

Please provide the following informations.

System version  5.1,6.0,6.0.1

Java version  1.8

Gradle version   5.1.1

Android Gradle plugin version  3.4.0

Booster version 0.22.0

java.lang.ClassCastException:java.lang.Class cannot be cast to java.util.concurrent.ThreadPoolExecutor$Worker
java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:756)
java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:779)
java.util.concurrent.ThreadPoolExecutor.allowCoreThreadTimeOut(ThreadPoolExecutor.java:1615)
com.didiglobal.booster.instrument.ShadowExecutors.java.util.concurrent.ExecutorService newOptimizedCachedThreadPool(java.lang.String)(SourceFile:7)
org.greenrobot.eventbus.EventBusBuilder.void ()(SourceFile:1)
org.greenrobot.eventbus.EventBus.void ()(SourceFile:1)

麻烦提供一下报异常的 class 文件

请试一下最新的Booster版本

authors: forJrking johnsonlee neighbWang

repo: didi/booster


text:
官网上swiper控件描述错误

Mand Mobile Version

OS Version & Browser Version

Node Version, Package Management Tool

Recurring Links

Recurring Steps

Expectant Behaviors

Actual Behaviors

在调用前一个方法时应该是this.$refs.step.prev()，官网的描述是this.$refs.step.pre();

repo: didi/mand-mobile


text:
数据大屏数据收集正常但是设置报警规则不生效，报警规则没有触发

What happened:
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

OS (e.g: cat /etc/os-release):
Logs:
Others:

设置报警的redis端口配置错误导致的，已解决

设置报警的redis端口配置错误导致的，已解决

repo: didi/nightingale


text:
eslint配置文件.eslintrc.js中的JavaScript Standard Style是完整的吗？

@didilinkin
RT
我的意思是
// 以下规则为 'Standard' 规范( 无修改 )
        // "indent": [ "error", 2 ],                                                   // 两格缩进
        "quotes": [ "error", "single" ],                                            // 必须使用单引号
        "no-unused-vars": "error",                                                  // 不要定义未使用的变量
        "keyword-spacing": [ "error", { "before": true } ],                         // 关键字后面加空格
        "space-before-function-paren": "error",                                     // 函数声明时括号与函数名间加空格
        "eqeqeq": [ "error", "always" ],                                            // 使用 === 替代 ==
        "space-infix-ops":  "error",                                                // 字符串拼接操作符 (Infix operators) 之间要留空格
        "comma-spacing": [ "error", { "before": false, "after": true } ],           // 逗号前面禁止 加空格 / 逗号后面必须 加空格
        "brace-style": "error",                                                     // 关键字要与花括号保持在同一行
        "curly": "error",                                                           // 多行 if 语句的的括号不能省
        "handle-callback-err": "error",                                             // 不要丢掉异常处理中err参数
        "no-undef": "error",                                                        // 使用浏览器全局变量时加上 window. 前缀
        "no-multiple-empty-lines": ["error", { "max": 2, "maxBOF": 1 }],            // 不允许有连续多行空行
        // "operator-linebreak": [ "error", "after" ],                                 // 对于三元运算符 ? 和 : 与他们所负责的代码处于同一行( 所有的运算符必须在同一行 )
        "one-var": [ "error", { var: "never", let: "never", const: "never" } ],     // 每个 var 关键字单独声明一个变量
        "no-cond-assign": "error",                                                  // 条件语句中赋值语句使用括号包起来。这样使得代码更加清晰可读，而不会认为是将条件判断语句的全等号（===）错写成了等号（=）
        "block-spacing": "error",                                                   // 单行代码块两边加空格
        "camelcase": "error",                                                       // 对于变量和函数名统一使用驼峰命名法
        "comma-dangle": [ "error", "never" ],                                       // 不允许有多余的行末逗号
        "comma-style": [ "error", "last" ],                                         // 始终将逗号置于行末
        "dot-location": [ "error", "object" ],                                      // 点号操作符须与属性需在同一行
        "eol-last": [ "error", "always" ],                                          // 文件末尾留一空行
        "func-call-spacing": ["error", "never"],                                    // 函数调用时标识符与括号间不留间隔
        "key-spacing": [ "error", { "beforeColon": false } ],                       // 键值对当中冒号与值之间要留空白
        "new-cap" : "error",                                                        // 构造函数要以大写字母开头
        "new-parens": "error",                                                      // 无参的构造函数调用时要带上括号
        "accessor-pairs": "error",                                                  // 对象中定义了存值器，一定要对应的定义取值器
        "constructor-super": "error",                                               // 子类的构造器中一定要调用 super
        "no-array-constructor": "error",                                            // 使用数组字面量而不是构造器( 禁止使用 Array 构造函数 )
        "no-caller": "error",                                                       // 避免使用 arguments.callee 和 arguments.caller
        "no-class-assign": "error",                                                 // 避免对类名重新赋值
        "no-const-assign": "error",                                                 // 避免修改使用 const 声明的变量
        "no-constant-condition": "error",                                           // 避免使用常量作为条件表达式的条件( 循环语句除外 )
        "no-control-regex": "error",                                                // 正则中不要使用控制符
        //"no-debugger": "error",                                                     // 不要使用 debugger
        "no-delete-var": "error",                                                   // 不要对变量使用 delete 操作
        "no-dupe-args": "error",                                                    // 不要定义冗余的函数参数
        "no-dupe-class-members": "error",                                           // 类中不要定义冗余的属性
        "no-dupe-keys": "error",                                                    // 对象字面量中不要定义重复的属性
        "no-duplicate-case": "error",                                               // switch 语句中不要定义重复的 case 分支
        "no-duplicate-imports": "error",                                            // 同一模块有多个导入时一次性写完
        "no-empty-character-class": "error",                                        // 正则中不要使用空字符
        "no-empty-pattern": "error",                                                // 不要解构空值
        "no-eval": "error",                                                         // 不要使用 eval()
        "no-ex-assign": "error",                                                    // catch 中不要对错误重新赋值
        "no-extend-native": "error",                                                // 不要扩展原生对象
        "no-extra-bind": "error",                                                   // 避免多余的函数上下文绑定
        "no-extra-boolean-cast": "error",                                           // 避免不必要的布尔转换
        // "no-extra-parens": "error",                                                 // 不要使用多余的括号包裹函数
        "no-fallthrough": "error",                                                  // switch 一定要使用 break 来将条件分支正常中断
        "no-floating-decimal": "error",                                             // 不要省去小数点前面的0
        "no-func-assign": "error",                                                  // 避免对声明过的函数重新赋值
        "no-global-assign": "error",                                                // 不要对全局只读对象重新赋值
        "no-implied-eval": "error",                                                 // 注意隐式的 eval()
        "no-inner-declarations": "error",                                           // 嵌套的代码块中禁止再定义函数
        "no-invalid-regexp": "error",                                               // 不要向 RegExp 构造器传入非法的正则表达式
        "no-irregular-whitespace": "error",                                         // 不要使用非法的空白符
        "no-iterator": "error",                                                     // 禁止使用 __iterator__
        "no-label-var": "error",                                                    // 外部变量不要与对象属性重名
        "no-labels": "error",                                                       // 不要使用标签语句
        "no-lone-blocks": "error",                                                  // 不要书写不必要的嵌套代码块
        "no-mixed-spaces-and-tabs": "error",                                        // 不要混合使用空格与制表符作为缩进
        // "no-multi-spaces": "error",                                                 // 除了缩进，不要使用多个空格
        "no-multi-str": "error",                                                    // 不要使用多行字符串
        "no-new": "error",                                                          // new 创建对象实例后需要赋值给变量
        "no-new-func": "error",                                                     // 禁止使用 Function 构造器
        "no-new-object": "error",                                                   // 禁止使用 Object 构造器
        "no-new-require": "error",                                                  // 禁止使用 new require
        "no-new-symbol": "error",                                                   // 禁止使用 Symbol 构造器
        "no-new-wrappers": "error",                                                 // 禁止使用原始包装器
        "no-obj-calls": "error",                                                    // 不要将全局对象的属性作为函数调用
        "no-octal": "error",                                                        // 不要使用八进制字面量
        "no-octal-escape": "error",                                                 // 字符串字面量中也不要使用八进制转义字符
        "no-path-concat": "error",                                                  // 使用 __dirname 和 __filename 时尽量避免使用字符串拼接
        "no-proto": "error",                                                        // 使用 getPrototypeOf 来替代 __proto__
        "no-redeclare": "error",                                                    // 不要重复声明变量
        "no-regex-spaces": "error",                                                 // 正则中避免使用多个空格
        "no-return-assign": "error",                                                // return 语句中的赋值必需有括号包裹
        "no-self-assign": "error",                                                  // 避免将变量赋值给自己
        "no-self-compare": "error",                                                 // 避免将变量与自己进行比较操作
        "no-sequences": "error",                                                    // 避免使用逗号操作符
        "no-shadow-restricted-names" : "error",                                     // 不要随意更改关键字的值
        "no-sparse-arrays": "error",                                                // 禁止使用稀疏数组（Sparse arrays）
        "no-tabs" : "error",                                                        // 不要使用制表符
        "no-template-curly-in-string" : "error",                                    // 正确使用 ES6 中的字符串模板
        "no-this-before-super": "error",                                            // 使用 this 前请确保 super() 已调用
        "no-throw-literal": "error",                                                // 用 throw 抛错时，抛出 Error 对象而不是字符串
        "no-trailing-spaces": "error",                                              // 行末不留空格
        "no-undef-init": "error",                                                   // 不要使用 undefined 来初始化变量
        "no-unmodified-loop-condition": "error",                                    // 循环语句中注意更新循环变量
        "no-unneeded-ternary" : "error",                                            // 如果有更好的实现，尽量不要使用三元表达式
        "no-unreachable": "error",                                                  // return，throw，continue 和 break 后不要再跟代码
        "no-unsafe-finally" : "error",                                              // finally 代码块中不要再改变程序执行流程
        "no-unsafe-negation": "error",                                              // 关系运算符的左值不要做取反操作
        "no-useless-call": "error",                                                 // 避免不必要的 .call() 和 .apply()
        "no-useless-computed-key": "error",                                         // 避免使用不必要的计算值作对象属性
        "no-useless-constructor": "error",                                          // 禁止多余的构造器
        "no-useless-escape": "error",                                               // 禁止不必要的转义
        "no-useless-rename": "error",                                               // import, export 和解构操作中，禁止赋值到同名变量
        "no-whitespace-before-property": "error",                                   // 属性前面不要加空格
        "no-with": "error",                                                         // 禁止使用 with
        "object-property-newline": "error",                                         // 对象属性换行时注意统一代码风格
        "padded-blocks": [ "error", "never" ],                                                   // 代码块中避免多余留白
        "rest-spread-spacing": "error",                                             // 展开运算符与它的表达式间不要留空白
        "semi-spacing": "error",                                                    // 遇到分号时空格要后留前不留
        "space-before-blocks": "error",                                             // 代码块首尾留空格
        "space-in-parens": "error",                                                 // 圆括号间不留空格
        "space-unary-ops": "error",                                                 // 一元运算符后面跟一个空格
        "spaced-comment": "error",                                                  // 注释首尾留空格
        "template-curly-spacing": "error",                                          // 模板字符串中变量前后不加空格
        "use-isnan": "error",                                                       // 检查 NaN 的正确姿势是使用 isNaN()
        "valid-typeof": "error",                                                    // 用合法的字符串跟 typeof 进行比较操作
        "wrap-iife": "error",                                                       // 自调用匿名函数 (IIFEs) 使用括号包裹
        "yield-star-spacing": "error",                                              // yield * 中的 * 前后都要有空格
        "yoda": "error",                                                            // 请书写优雅的条件语句（avoid Yoda conditions）
        "semi": [ "error", "never" ],                                               // 不要使用分号
        "no-unexpected-multiline": "error",                                         // 禁止使用令人困惑的多行表达式

这部分是完整的JavaScript Standard Style吗？

对， 是根据 我当时开发的 standard 规范， 完整的抄下来的( 花了好多时间... )
有些地方 我要做调整的， 就直接注释掉， 然后在下面重写写一份。 所以 ， 你说的没有错

@pei-han  我是根据 这个文件配置的 https://github.com/standard/standard/blob/master/docs/RULES-zhcn.md#javascript-standard-style  可以看看。
他有可能更新了

@didilinkin  129条？

@didilinkin 注释掉的是什么情况？

@pei-han 注释是因为我当时 不想用 2格缩进； 我也记不住一共多少条了。 其实你要是能接受， 直接把我的rule全删了， 改为 standard 的 plug 也行 ， 这样 就最完整。
我当时是看到有多少条， 就记录多少。 所以数据跟现在的有差距 也比较正常

@pei-han 下面还有一些 我自己写的 加强检查 感觉也挺好用

@didilinkin 是的，我也发现了你的rule和eslint-config-standard中的差异，才这么一问。
你这么一说，我就明白了

@didilinkin  我不了解你用什么编辑器来开发。我使用sublime text，是否有格式化的插件等可以按照eslint配置文件的code style来自动格式化代码？我想，
这样的话不需要项目的成员纠结于code style，因为学习这么多rule短时间是有困难的，我的想法是，先配置好，先用起来，慢慢的熟悉

@pei-han 有的， 推荐用 vs code , 那个里面有一键自动格式化， 非常方便。 可以看一下 vscode 的 eslint 插件 和 配置

@didilinkin  在eslint-config-standard这个shareable config中看到有这样一条rule
"no-use-before-define": ["error", { "functions": false, "classes": false, "variables": false }]
但是，在您的.eslintrc.js文件中，没有看到这条rule
而且，在https://standardjs.com/rules.html上也没有看到这条rule
请问是怎么回事？

也许是后加的？如果 那个rules 上没有的话， 我也不会写上。 不用太纠结。 用 standard 最新版就好

@didilinkin  我是奇怪，在https://standardjs.com/rules.html 上也没有看到这条rule，然而，在eslint-config-standard这个shareable config中看到有这样一条rule

@pei-han 还是以这个为标准吧： https://github.com/standard/eslint-config-standard/blob/master/eslintrc.json

authors: didilinkin pei-han

repo: didilinkin/react-admin-antd


text:
Highlight color

Thanks for the extension! It has made using Hypothesis much easier. I was wondering if different colors can be assigned to highlights. Currently, there's only one color. Could there be an option of 2 or 3 additional colors? It will help with the visual classification of highlights.

Hi, Shailen! I'm happy you are enjoying the extension. I like your suggestion. In fact, I have long thought of adding a filtering system such that one can define a series of rules -based on annotation tags, creator, etc- and apply different styles to them. For example, "make annotations with the label 'hypothesis' red", or "make annotations created by 'me' blue", or "hide annotations made by 'johndoe'", etc.
Unfortunately, I have been very busy lately and I haven't been able to work on this or any of my other ideas. In fact, maybe you have noticed I haven't even been able to keep up with newer Hypothesis versions.
Right now I'm just making sure the add-on continues to work. I'm using it myself after all! For example, a couple weeks ago I had to update the unofficial client to make sure Mozilla wouldn't remove the addon from AMO (addons.mozilla.org). But that's pretty much all I'm finding the time to commit to right now, I'm afraid.
Let's keep the issue open though in case me or somebody else can do it later.
Anyway, I suggest you follow the discussion about multiple highlight colors in the official Hypothesis channels too. See here, for example.

Hi Diego, Thank you for your quick response. I fully understand the crunch of time you must be facing. Thanks for supplying us--the users--necessary updates to keep the add-on working well for us. Thanks for keeping the issue open in the mean time. I wish I was a programmer and I could have contributed to the add-on in some way. Hopefully, some else will pitch in. I will follow the discussion on Hypothesis's forum and add my input there!

authors: diegodlh shailenmishra


text:
[helm] rename helm chart libra-reference-wallet to reference-wallet

Rename libra-reference-wallet helm chart to reference-wallet. If you already have an existing helm release and wish to upgrade to this new version, you'll have to helm uninstall first due to reuse of the same helm release name.

@yanivmo can you check on liquidity side if the helm charts have everything we need with the new liquidity service?

Besides rename, just some minor changes to make sure the environment variables work with liquidity-emulator.

authors: rustielin sunmilee

repo: diem/reference-wallet


text:
[depdive] analyze version diff from crates.io hosted code in stead of fetching from repository

should be more deterministic

#104

repo: diem/whackadep


text:
create postgres user via sql_query with params throw an error

Setup
Versions

Rust: 1.58.1
Diesel: 1.4.8
Database: PostgreSQL 14.1
Operating System Ubuntu 20.04.4

Feature Flags

diesel: postgres

Problem Description
What are you trying to accomplish?
I try to create new postgres users with the sql_query function with parameters.
sql_query("CREATE USER $1 WITH PASSWORD '$2'")
        .bind::<Text, _>(&name)
        .bind::<Text, _>(&password)
        .execute(&conn)
        .unwrap();

What is the expected output?
It should create a new user.
What is the actual output?
DatabaseError(__Unknown, "syntax error at or near \"$1\"")'
Are you seeing any additional errors?
If I don't use the param syntax I can create new users:
sql_query("CREATE USER admin WITH PASSWORD 'admin'")
        .execute(&conn)
        .unwrap();

And the param syntax works, if i use it in an SELECT call:
#[derive(Debug, QueryableByName)]
struct TestStruct {
    #[sql_type = "Text"]
    text: String
}

...

let list = sql_query("SELECT $1 as text")
        .bind::<Text, _>(&name)
        .load::<TestStruct>(&conn)
        .unwrap();
    println!("{:?}", list);

So I don't understand why I can create new users via query and I can use the params in another case, but I can't combine them.
It would be great to use it with diesel directly.
Steps to reproduce
use diesel::{Connection, PgConnection, RunQueryDsl, sql_query};
use diesel::sql_types::Text;

fn establish_connection() -> PgConnection {
    let database_url = "postgres://anthill:anthill@localhost:15432/anthill".to_string();
    PgConnection::establish(&database_url)
        .expect(&format!("Error connecting to {}", &database_url))
}

fn create_pg_user(name: &String, password: &String) {
    let conn = establish_connection();

    sql_query("CREATE USER $1 WITH PASSWORD $2")
        .bind::<Text, _>(&name)
        .bind::<Text, _>(&password)
        .execute(&conn)
        .unwrap();
}

fn main() {
    create_pg_user(&"admin".to_string(), &"password".to_string());
}

Checklist

[x] I have already looked over the issue tracker  and the disussion forum  for similar possible closed issues.
[x] This issue can be reproduced on Rust's stable channel. (Your issue will be
closed if this is not the case)
[x] This issue can be reproduced without requiring a third party crate

Thanks for raising this report. This error indicates that posgres does not allow bind parameters in this position.
Closed as this is not a diesel bug, as we don't do any query processing for sql_query.

authors: Corfus weiznich

repo: diesel-rs/diesel


text:
Compile error when trying to use infer_schema!() against existing database

RUST_BACKTRACE=1 cargo build
   Compiling diesel_demo v0.1.0 (file:///mnt/storage/dev/postgres/diesel_demo)
error[E0428]: a type named `_Dummy` has already been defined in this module
 --> src/schema.rs:1:1
  |
1 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  | |
  | previous definition of `_Dummy` here
  | already defined
  |
  = note: this error originates in a macro outside of the current crate

error[E0428]: a type named `_Dummy` has already been defined in this module
 --> src/schema.rs:1:1
  |
1 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  | |
  | previous definition of `_Dummy` here
  | already defined
  |
  = note: this error originates in a macro outside of the current crate

error[E0428]: a type named `_Dummy` has already been defined in this module
 --> src/schema.rs:1:1
  |
1 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  | |
  | previous definition of `_Dummy` here
  | already defined
  |
  = note: this error originates in a macro outside of the current crate

error[E0428]: a type named `_Dummy` has already been defined in this module
 --> src/schema.rs:1:1
  |
1 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  | |
  | previous definition of `_Dummy` here
  | already defined
  |
  = note: this error originates in a macro outside of the current crate

error[E0428]: a type named `_Dummy` has already been defined in this module
 --> src/schema.rs:1:1
  |
1 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  | |
  | previous definition of `_Dummy` here
  | already defined
  |
  = note: this error originates in a macro outside of the current crate

error[E0428]: a type named `_Dummy` has already been defined in this module
 --> src/schema.rs:1:1
  |
1 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  | |
  | previous definition of `_Dummy` here
  | already defined
  |
  = note: this error originates in a macro outside of the current crate

error[E0428]: a type named `_Dummy` has already been defined in this module
 --> src/schema.rs:1:1
  |
1 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  | |
  | previous definition of `_Dummy` here
  | already defined
  |
  = note: this error originates in a macro outside of the current crate

error[E0428]: a type named `_Dummy` has already been defined in this module
 --> src/schema.rs:1:1
  |
1 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  | |
  | previous definition of `_Dummy` here
  | already defined
  |
  = note: this error originates in a macro outside of the current crate

error: internal compiler error: ../src/librustc_metadata/decoder.rs:490: entry: id not found: DefIndex(1) in crate "diesel_codegen" with number 16

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'Box<Any>', ../src/librustc_errors/lib.rs:424
stack backtrace:
   1:     0x7f37fc2a405a - std::sys::imp::backtrace::tracing::imp::write::h944c02ac40aee2d7
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x7f37fc2b2eff - std::panicking::default_hook::{{closure}}::h6875a2976258b020
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:247
   3:     0x7f37fc2b2a9d - std::panicking::default_hook::h88ffbc5922643264
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:257
   4:     0x7f37fc2b33a7 - std::panicking::rust_panic_with_hook::ha5aed1dfc0e220e3
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:451
   5:     0x7f37f4dbb53a - std::panicking::begin_panic::h264cdc75d51b518b
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:413
   6:     0x7f37f4dcc0fd - rustc_errors::Handler::bug::h620f7270292f0095
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_errors/lib.rs:424
   7:     0x7f37f966ca11 - rustc::session::opt_span_bug_fmt::{{closure}}::h4a9b70c3df8b4b3a
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/session/mod.rs:771
   8:     0x7f37f966c82e - rustc::session::opt_span_bug_fmt::h7d83586c6e2c7ae6
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1048
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/session/mod.rs:767
   9:     0x7f37f966c492 - rustc::session::bug_fmt::he2d2f00a4afa9d1e
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/session/mod.rs:751
  10:     0x7f37f9fb2bb3 - rustc_metadata::decoder::<impl rustc_metadata::cstore::CrateMetadata>::entry::h5e3d8114267e9116
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_metadata/decoder.rs:490
  11:     0x7f37f9fbb0cb - rustc_metadata::cstore_impl::<impl rustc::middle::cstore::CrateStore<'tcx> for rustc_metadata::cstore::CStore>::visibility::h2949b511f18961ee
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_metadata/decoder.rs:654
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_metadata/cstore_impl.rs:58
  12:     0x7f37f9fc3510 - rustc_metadata::cstore_impl::<impl rustc::middle::cstore::CrateStore<'tcx> for rustc_metadata::cstore::CStore>::visible_parent_map::hab53861eb74bce8d
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_metadata/cstore_impl.rs:597
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_metadata/cstore_impl.rs:622
  13:     0x7f37f96b2124 - rustc::ty::item_path::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::push_item_path::haa7f7a9afda5f72a
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/item_path.rs:115
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/item_path.rs:152
  14:     0x7f37f96f91d3 - rustc::util::ppaux::parameterized::h7bcfb1fd3d8a947a
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/item_path.rs:49
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/util/ppaux.rs:154
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1035
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/thread/local.rs:245
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1031
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/util/ppaux.rs:82
  15:     0x7f37fc305515 - core::fmt::write::h01739b8f12f355f9
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcore/fmt/mod.rs:829
  16:     0x7f37fc3063b5 - core::fmt::Formatter::write_fmt::h50f274f007b40806
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcore/fmt/mod.rs:1134
  17:     0x7f37f9701962 - rustc::util::ppaux::<impl core::fmt::Display for rustc::ty::TraitPredicate<'tcx>>::fmt::he0dbf908fd919098
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/util/ppaux.rs:1022
  18:     0x7f37fc305515 - core::fmt::write::h01739b8f12f355f9
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcore/fmt/mod.rs:829
  19:     0x7f37fc3063b5 - core::fmt::Formatter::write_fmt::h50f274f007b40806
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcore/fmt/mod.rs:1134
  20:     0x7f37f96fe611 - rustc::util::ppaux::<impl core::fmt::Display for rustc::ty::sty::Binder<rustc::ty::TraitPredicate<'tcx>>>::fmt::hb2f823bd10699038
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/util/ppaux.rs:298
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/util/ppaux.rs:764
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1035
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/thread/local.rs:245
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1031
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/util/ppaux.rs:764
  21:     0x7f37fc305515 - core::fmt::write::h01739b8f12f355f9
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcore/fmt/mod.rs:829
  22:     0x7f37fc3063b5 - core::fmt::Formatter::write_fmt::h50f274f007b40806
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcore/fmt/mod.rs:1134
  23:     0x7f37f9701c31 - rustc::util::ppaux::<impl core::fmt::Display for rustc::ty::Predicate<'tcx>>::fmt::hcaf28c3b7b8ea3ed
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/util/ppaux.rs:1063
  24:     0x7f37fc305515 - core::fmt::write::h01739b8f12f355f9
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcore/fmt/mod.rs:829
  25:     0x7f37fc2be60d - collections::fmt::format::h2e5dd97da45bd3ab
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcore/fmt/mod.rs:130
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcollections/fmt.rs:543
  26:     0x7f37f967422a - rustc::traits::error_reporting::<impl rustc::infer::InferCtxt<'a, 'gcx, 'tcx>>::report_selection_error::h962cd4a7e26d176d
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/traits/error_reporting.rs:491
  27:     0x7f37f966efb4 - rustc::traits::error_reporting::<impl rustc::infer::InferCtxt<'a, 'gcx, 'tcx>>::report_fulfillment_error::hb3520d160f1dddc3
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/traits/error_reporting.rs:80
  28:     0x7f37f966df01 - rustc::traits::error_reporting::<impl rustc::infer::InferCtxt<'a, 'gcx, 'tcx>>::report_fulfillment_errors::h9a88e2fc91b0b056
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/traits/error_reporting.rs:65
  29:     0x7f37fa76fa26 - rustc_typeck::check::FnCtxt::select_obligations_where_possible::hb71c39774d7865bc
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/mod.rs:2240
  30:     0x7f37fa76eed2 - rustc_typeck::check::FnCtxt::select_all_obligations_and_apply_defaults::he017bcec5f3ea226
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/mod.rs:1981
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/mod.rs:1975
  31:     0x7f37fa76f6f9 - rustc_typeck::check::FnCtxt::select_all_obligations_or_error::hec789b8269f0fa83
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/mod.rs:2221
  32:     0x7f37fa6a59c4 - <std::thread::local::LocalKey<T>>::with::h7d0b5ca65a1ab155
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/wfcheck.rs:59
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/mod.rs:471
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/infer/mod.rs:523
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1019
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/thread/local.rs:245
  33:     0x7f37fa730952 - rustc_typeck::check::wfcheck::CheckTypeWellFormedVisitor::check_item_well_formed::hbb7157febd75c937
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1016
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:853
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/infer/mod.rs:523
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/mod.rs:471
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/wfcheck.rs:53
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/wfcheck.rs:400
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/wfcheck.rs:115
  34:     0x7f37fa73bdfb - <rustc_typeck::check::wfcheck::CheckTypeWellFormedVisitor<'ccx, 'tcx> as rustc::hir::intravisit::Visitor<'v>>::visit_item::h25315dc7b01c34ff
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/wfcheck.rs:615
  35:     0x7f37fa752a5a - rustc_typeck::check::check_wf_new::h186f7cd379099246
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/dep_graph/visit.rs:46
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/hir/mod.rs:445
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/dep_graph/visit.rs:57
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/mod.rs:2703
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/mod.rs:537
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/session/mod.rs:222
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/check/mod.rs:535
  36:     0x7f37fa7bdefa - rustc_typeck::check_crate::h4045752b69a796e8
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/lib.rs:341
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/util/common.rs:38
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_typeck/lib.rs:341
  37:     0x7f37fc64da4e - rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}::h97a3a12d948df547
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_driver/driver.rs:891
  38:     0x7f37fc64aced - rustc_driver::driver::phase_3_run_analysis_passes::hb0ad9de18d423e67
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1019
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/thread/local.rs:245
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1016
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1003
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/thread/local.rs:245
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:1000
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/context.rs:789
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_driver/driver.rs:869
  39:     0x7f37fc632474 - rustc_driver::driver::compile_input::h8e119234b60571d5
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_driver/driver.rs:173
  40:     0x7f37fc677580 - rustc_driver::run_compiler::hbdfc4f84e2e0f4b9
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_driver/lib.rs:222
  41:     0x7f37fc5936b8 - std::panicking::try::do_call::hf679f17bf3b43b0b
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_driver/lib.rs:1141
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_driver/lib.rs:138
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc_driver/lib.rs:1075
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panic.rs:295
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:356
  42:     0x7f37fc2bd8ea - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libpanic_unwind/lib.rs:97
  43:     0x7f37fc5b7248 - <F as alloc::boxed::FnBox<A>>::call_box::h506fb5d7b8891cd4
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:332
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panic.rs:351
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/thread/mod.rs:287
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/liballoc/boxed.rs:595
  44:     0x7f37fc2b1d74 - std::sys::imp::thread::Thread::new::thread_start::h8084b1107992ae5b
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/liballoc/boxed.rs:605
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/sys_common/thread.rs:21
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/sys/unix/thread.rs:84
  45:     0x7f37f4565709 - start_thread
  46:     0x7f37fbf6c82c - clone
  47:                0x0 - <unknown>

error: Could not compile `diesel_demo`.

Enabling the "large-tables" feature fixes the compiler panic, but still getting warnings about _Dummy being defined multiple times.

IIRC, #493 aims to fix the _Dummy error

Oh good, nightlies are building again. This is fixed by https://github.com/diesel-rs/diesel/pull/493. I'll try to release tonight.

As a workaround in the short term you can use an older nightly.

That's alright. I was just walking through the getting started guide when I hit this, so I'm going to take a look at rust-postgres and check back later.  Thanks for your work on this, seems like it's going to be pretty awesome!

I just hit this too, couldn't finish step 1 in the getting_started guide.  Ah, nightlies!
Looks like rustc needs a little more time in the oven...  I'll try again in a few weeks.

All rust nightlies which have this issue are actually completely broken for procedural macros. It's all fixed on master, so we'll release tomorrow or the day after depending on when the nightly was rolled

Oh good.  I'll try again in a few days.
How far back to I need to go if I want to keep going tonight?  Maybe a month old nightly?

2016-11-06

rustup toolchain install nightly-2016-11-06, thanks!

Hm, late oct / early nov only appear to work on Linux.  Getting consistent ICEs on Mac:
thread 'rustc' panicked at 'index out of bounds: the len is 363930 but the index is 363930', ../src/libserialize/leb128.rs:47
note: Run with `RUST_BACKTRACE=1` for a backtrace.

owell, I'll try again in a few days.  sgrif, just curious: which platform to you use for Diesel dev?

Run cargo clean and recompile. Nightlies don't ship unless they work on all platforms. I use mac to develop primarily, and windows periodically.

Yep, that worked!  Thanks for ignoring my attempts to give up.

Hi, I am getting the same error on rustc 1.14.0-nightly (cae6ab1c4 2016-11-05)
error: custom derive attribute panicked  --> src/schema.rs:1:1   | 1 | infer_schema!("dotenv:DATABASE_URL");   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   |   = help: message: calledResult::unwrap()on anErr` value: StringError("Failed to load environment variable DATABASE_URL: environment variable not found")
= note: this error originates in a macro outside of the current crate
error: Could not compile diesel_demo.
`
I am using code from the examples directory to test diesel.

@nkhinchi Do you have the .env file or the environmental variable set up? That looks more like it's missing.

Thanks, that did the trick. I was struggling with the original error before.

0.8.2 has been released with a fix

Right on, looks great.  cargo update and everything works again.

authors: bronson ghotiphud golddranks killercup nkhinchi sgrif


text:
added postgres trim_array function

added the postgresql trim_array array function under #4153

Thanks for open the PR!
The code looks good to me

thanks for reviewing!


text:
Add AllowDraftPRs flag, disabled by default

Not tested yet in E2E flow, only in go testing

Thanks! I believe this is related to #1195 if I am not mistaken

@motatoes any chance you could test this locally? I can't seem to get my local stack up

Bump! :)

authors: motatoes ri-roee

repo: diggerhq/digger


text:
DNS name validator should not throw an error if an IP address is specified

I'm getting a few errors in this form:
GeneralNameDnsNameSyntaxValidator @ certificate.tbsCertificate.extensions.2.extnValue.subjectAltName.0.dNSName
    pkix.invalid_domain_name_syntax (ERROR): Invalid domain name syntax: "192.168.1.102"

The corresponding RFC does state that DNS can specify an IP address:
From https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.6
When the subjectAltName extension contains a domain name system
   label, the domain name MUST be stored in the dNSName (an IA5String).
   The name MUST be in the "preferred name syntax", as specified by
   [Section 3.5 of [RFC1034]](https://www.rfc-editor.org/rfc/rfc1034#section-3.5) and as modified by Section 2.1 of
   [RFC1123].

Then from the linked https://www.rfc-editor.org/rfc/rfc1123#page-13
Whenever a user inputs the identity of an Internet host, it SHOULD
      be possible to enter either (1) a host domain name or (2) an IP
      address in dotted-decimal ("#.#.#.#") form.

I think this particular error should be either removed or downgraded to a WARNING at least, or maybe just an INFO?

Hi @jon-oracle, thanks for filing this.
The passage you quoted in RFC 1123 makes it clear that an quad-octet dotted IP address is discrete from a host domain name (otherwise there would be no need to enumerate these two different types). Additionally, the last paragraph of RFC 1123, section 2.1 says:

However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic.

Thus, it is clear that a dNSName cannot contain a dotted IP address, as it must contain a valid host name. This is the interpretation taken by the WebPKI, where cases of CAs encoding IPv4 addresses in dNSNames have been treated as non-compliance with RFC 5280.
Given this, I don't have any plans of changing the current behavior. However, I'll keep this issue open for a few more days if you have any follow-up feedback.

Closing for now, please comment if there's any follow-up.

authors: CBonnell jon-oracle

repo: digicert/pkilint


text:
Properly reference logout commands in apis.rst

When docs are re-enabled for 3.x: https://github.com/DACH-NY/canton/issues/16155
Replace with references to the commands, e.g.
:ref:`participant <domains.logout>`

and
:ref:`mediator <sequencer_connection.logout>`

CC @cgrigis-da
Replaced by https://github.com/DACH-NY/canton/issues/22919

Thank you @yves-da!

authors: cgrigis-da yves-da


text:
「部」が重複

Example Data
"佐賀県鹿島市三部","佐賀県鹿島市三部部",0.89,"machiaza_detail"
"兵庫県養父市一部","兵庫県養父市一部部",0.89,"machiaza_detail"
"北海道夕張市一部","北海道夕張市一部部",0.89,"machiaza_detail"
"北海道夕張市七部","北海道夕張市七部部",0.89,"machiaza_detail"
"北海道夕張市三部","北海道夕張市三部部",0.89,"machiaza_detail"
"北海道夕張市二部","北海道夕張市二部部",0.89,"machiaza_detail"
"北海道夕張市五部","北海道夕張市五部部",0.89,"machiaza_detail"
"北海道夕張市六部","北海道夕張市六部部",0.89,"machiaza_detail"
"北海道夕張市四部","北海道夕張市四部部",0.89,"machiaza_detail"
"山形県米沢市六部","山形県米沢市六部部",0.89,"machiaza_detail"
"石川県珠洲市若山町向元東若山村大字火宮壱部","石川県珠洲市若山町向元東若山村大字火宮壱部部",0.96,"machiaza_detail"
"石川県珠洲市飯田町元東若山村大字出田四弐部","石川県珠洲市飯田町元東若山村大字出田四弐部部",0.96,"machiaza_detail"
"石川県珠洲市上戸町南方元見付村大字春日野五部","石川県珠洲市上戸町南方元見付村大字春日野五部部",0.96,"machiaza_detail"
"石川県珠洲市若山町古蔵元西若山村大字向弐弐部","石川県珠洲市若山町古蔵元西若山村大字向弐弐部部",0.96,"machiaza_detail"
"石川県珠洲市若山町広栗元直村大字野々江壱〇部","石川県珠洲市若山町広栗元直村大字野々江壱〇部部",0.96,"machiaza_detail"
"石川県珠洲市若山町広栗元直村大字野々江壱弐部","石川県珠洲市若山町広栗元直村大字野々江壱弐部部",0.96,"machiaza_detail"
"石川県珠洲市若山町火宮元西若山村大字国兼九部","石川県珠洲市若山町火宮元西若山村大字国兼九部部",0.96,"machiaza_detail"
"石川県珠洲市若山町経念元西若山村大字国兼九部","石川県珠洲市若山町経念元西若山村大字国兼九部部",0.96,"machiaza_detail"
"石川県珠洲市若山町鈴内元直村大字野々江壱〇部","石川県珠洲市若山町鈴内元直村大字野々江壱〇部部",0.96,"machiaza_detail"
"石川県珠洲市若山町火宮元西若山村大字延武壱九部","石川県珠洲市若山町火宮元西若山村大字延武壱九部部",0.96,"machiaza_detail"

git log
% git log -1
commit 039262be6052206752f0466e803f739ddf47f420 (HEAD -> develop, origin/develop)
Author: Masashi Katsumata <maskatsum@digital.go.jp>
Date:   Sun Nov 10 23:25:58 2024 -0800

    wip: fixing memory leak

件数
% grep "部部" ./output_combined.220.csv|wc -l
    1684

ありがとうございます。
コミット #72ede24dd20438d519c5d50a0586b948d7fa15b4 では確認できませんでした。
たぶんどこかで直しています。
input,output,score,match_level
"佐賀県鹿島市三部","佐賀県鹿島市三部",1,"machiaza_detail"
"兵庫県養父市一部","兵庫県養父市一部",1,"machiaza_detail"
"北海道夕張市一部","北海道夕張市一部",1,"machiaza_detail"
"北海道夕張市七部","北海道夕張市七部",1,"machiaza_detail"
"北海道夕張市三部","北海道夕張市三部",1,"machiaza_detail"
"北海道夕張市二部","北海道夕張市二部",1,"machiaza_detail"
"北海道夕張市五部","北海道夕張市五部",1,"machiaza_detail"
"北海道夕張市六部","北海道夕張市六部",1,"machiaza_detail"
"北海道夕張市四部","北海道夕張市四部",1,"machiaza_detail"
"山形県米沢市六部","山形県米沢市六部",1,"machiaza_detail"
"石川県珠洲市若山町向元東若山村大字火宮壱部","石川県珠洲市若山町向元東若山村大字火宮壱部",1,"machiaza_detail"
"石川県珠洲市飯田町元東若山村大字出田四弐部","石川県珠洲市飯田町元東若山村大字出田四弐部",1,"machiaza_detail"
"石川県珠洲市上戸町南方元見付村大字春日野五部","石川県珠洲市上戸町南方元見付村大字春日野五部",1,"machiaza_detail"
"石川県珠洲市若山町古蔵元西若山村大字向弐弐部","石川県珠洲市若山町古蔵元西若山村大字向弐弐部",1,"machiaza_detail"
"石川県珠洲市若山町広栗元直村大字野々江壱〇部","石川県珠洲市若山町広栗元直村大字野々江壱〇部",1,"machiaza_detail"
"石川県珠洲市若山町広栗元直村大字野々江壱弐部","石川県珠洲市若山町広栗元直村大字野々江壱弐部",1,"machiaza_detail"
"石川県珠洲市若山町火宮元西若山村大字国兼九部","石川県珠洲市若山町火宮元西若山村大字国兼九部",1,"machiaza_detail"
"石川県珠洲市若山町経念元西若山村大字国兼九部","石川県珠洲市若山町経念元西若山村大字国兼九部",1,"machiaza_detail"
"石川県珠洲市若山町鈴内元直村大字野々江壱〇部","石川県珠洲市若山町鈴内元直村大字野々江壱〇部",1,"machiaza_detail"
"石川県珠洲市若山町火宮元西若山村大字延武壱九部","石川県珠洲市若山町火宮元西若山村大字延武壱九部",1,"machiaza_detail"

repo: digital-go-jp/abr-geocoder


text:
middleware: Add Error() to ErrorResponse

To be in sync with the rpcmessages.go in the bitbox-wallet-app a
Error() string method is added to the ErrorResponse. Additionally the
ErrorResponse in GetHostnameResponse is unembedded to separate
namespaces more clearly.
https://github.com/digitalbitbox/bitbox-wallet-app/pull/506/commits/788e92fed16b7f157597829e2f2f1c0f6a4ba839

Great, thanks for updating it.

repo: digitalbitbox/bitbox-base


text:
docs: Add build-details.md doc

This piece of documentation goes into a bit more depth about
how the Armbian build process works, specifically which scripts
copy which files from host -> overlay -> Armbian filesystem,
and which scripts have which responsibilities.
~Edit: This PR doesn't directly depend on https://github.com/digitalbitbox/bitbox-base/pull/56, but it does describe the Armbian build process as being dockerized, so probably would make sense to merge that PR first.~

Thanks for the review, @Stadicus!
I've force-pushed https://github.com/digitalbitbox/bitbox-base/commit/7b1a3ad5dab6bcafeff624428fb952e9459fe818 which addresses your review comments, PTAL.

ACK

authors: Stadicus hkjn


text:
Used contact form validation library does not support new TLDs

Switch to another validation library. Maybe after moving to the latest bootstrap version.
Relevant issue:
https://github.com/ReactiveRaven/jqBootstrapValidation/issues/185

For now the library is hot patched. To make this clear the library is marked as -dirty in its version.
Probably best to leave it open as switching to a newer library might still be worth it.

Probably best to leave it open as switching to a newer library might still be worth it.

I agree. jqBootstrapValidation doesn't seem to be actively maintained.

Suggestion is https://jqueryvalidation.org/.
Will see, if I can migrate in the coming days.

authors: digitalcraftsman stp-ip

repo: digitalcraftsman/hugo-agency-theme


text:
Hugo's DisableRSS should be used instead of EnableRSS

EnableRSS is used in this theme, but the Hugo uses DisableRSS. This means the site configuration file can set both flags individually, which is awkward (and can lead to errors, like if both are true or false).
Ideally this theme would use Hugo's variable (DisableRSS) instead of introducing a new alternative.
(And thanks for the nice port of the Cactus theme!)

As it turned out, not all config parameters are accessable inside a template, which includes DisableRSS. You can find further information in this forum post.

Dang, you're right. Even trying {{ if .RSSlink }} like the docs show doesn't seem to work. .RSSlink seems to be present even if DisableRSS is set to true.
Well, in that case, you can close this issue if you like, seeing as this is a deficiency of Hugo and not the theme.
Thanks for checking this out!

I agree with you that the use of both variables can be confusing, but I'll close the docs for now, since this seems to be a neccessary workaround. However, I'll have a look on this and asked in the forum post, if there are specific reasons for not making the configuration options accessable.

authors: digitalcraftsman mjbshaw

repo: digitalcraftsman/hugo-cactus-theme

license: mit


text:
Enforce types during tests

Motivation

At the moment, types are only checked statically via mypy. mypy does not execute the code, but just analyze it. It would be cool to check the types during the tests and make sure that all variables really have the expected types during runtime.
Proposed Solution

Not sure how we could achieve this, one possibility is the library strongtyping which provides a decorator @match_typing which throws an exception if a function call does not match its type annotations.
However, adding this to every function in the entire code base seems like a lot of overhead. Maybe we could achieve this by patching this dynamically just before the tests are run? (Either via monkeypatching or via a stupid regex-replacement of def occurrences...)
Alternatives

Rely on the current mypy checking

This might also be useful, even though it does not exactly what we want: https://mypy.readthedocs.io/en/stable/stubtest.html

This might also be useful, even though it does not exactly what we want: https://mypy.readthedocs.io/en/stable/stubtest.html

Good point! This is also what I used for the initial baseline of the types, but it required a lot of manual adjusting, would probably complicated to integrate into an automated workflow. But yes, we should investigate this when tackling this issue.

authors: david-venhoff timobrembeck

repo: digitalfabrik/integreat-cms


text:
Feature/global push notifications

Short description
This PR makes Push Notifications assignable to multiple regions.
Proposed changes

Replace PushNotification.region in model with a ManyToManyField .regions
Add CheckboxSelectMultiple to the PushNotificationForm, fed by [request.region]+list(request.region_selection) (ten regions the user has access to, including the current one)

Known problems and TODOs

forgot to adapt FirebaseApiClient, oops

Migration not properly reversible: getting django.db.utils.IntegrityError: column "region_id" of relation "cms_pushnotification" contains null values

If PushNotification.regions becomes empty, the object won't be deleted (CASCADE on the earlier ReferenceField not adapted for ManyToManyField)

No handling of any besides the trivial case:
If a user has access to region A and B and creates a PushNotification for both, a user who has access to region B and C will only get B and C displayed as options (with B selected), and have no indication that the PushNotification is also assigned to A. This will require a thorough discussion on how to handle such cases in the future.

Documentation, Changelog etc. missing

Tests missing incomplete?

Side effects

should be pretty contained
Resolved issues

Fixes: #2187

Pull Request Review Guidelines

To be honest, I am not sure that this approach is ideal for us. The feature seems to be a bit 'hacky' to me, as conceptually push notifications for multiple regions should not be managed at the region level. Maybe it would be better to move this functionality to the network management tab?
The current implementation is confusing, as it is not clear to me what should happen in the current edge cases that Peter already mentioned (For example should an editor of only one region be able to see a push notification for multiple regions, if that includes the editors region? And if so, should they be able to edit it? What should happen if such a user edits that push notification?)
I think the alternative mentioned by Ulli in the issue sounds better, because that would provide a single place where editors could create push notifications and then only need to select regions when sending them.

waiting for further communication with party requesting this feature

authors: PeterNerlich david-venhoff


text:
Find Next Available Prefix out of Aggregate

Issue type
[x] Feature request
[ ] Bug report
[ ] Documentation

Environment

Python version:  3.6
NetBox version:  2.3.3

Description
Would request implementing the next-available-prefix to also be able to get the next available prefix from an aggregate. Using the aggregate as the top level of address space allocated and able to go to the aggregate page to use as a report of available space is valuable. Thus looking to be able to get prefixes out of that space.
Probably a duplication/call to the same code used on prefixes.

Aggregates define the top level of your IP space hierarchy. They're not really intended to be allocated directly other than by human-driven policy, so I don't think it makes sense to enable blind allocation like we have for prefixes. You can, however, create a container prefix the same size as your aggregate and allocate new prefixes that way.

authors: jeremystretch jvanderaa

repo: digitalocean/netbox


text:
Ownership of Cables / Tenant view

Environment

Python version:  3.6.6
NetBox version:  2.5.8

Proposed Functionality
Currently, a tenant's device might be linked to another tenant or provider device via one ore more cables.  It is not possible to see easily identify all connections across tenants. Therefore Cables need to have a tenant ownership or else there needs to be a view that shows all cables related to a tenant.
Use Case
As a data center and that uses Netbox we maintain a full list of equipment, customer and own.  Currently it is possible to assign an ID to all services provided to a customer (tenant).  Prior to the introduction of cables in Netbox, a Circuit (type: "Uplink") was used to indicate the physical link providing the customer connectivity.  The tenant of such an ID was the customer.  This allows for a comprehensive view of everything a customer(tenant) has, i.e. all devices, racks, vlans, IPs, physical uplinks, circuits etc.
Having a cable that is assignable to a tenant or being able to filter all cables connecting to a tenant's device would restore this ability without having to resort to using Circuits (which is incorrect as it creates two cables when there would be one).
Database Changes
External Dependencies

There is no need to declare an explicit relationship to a tenant on the cable model, as the endpoints of a cable already have this association. (It also begs the question: who would own a cable connecting tenants A and B?)
It sounds like you want to be able to filter cables based on the tenant assigned to either end. If this is the case, please revise your FR to better capture the use case and remove the proposed relationship (or close this and open a new FR if you prefer).

Updated FR, thanks.

authors: jeremystretch xonacs


text:
intial work on #2647 - caching

Fixes: #2647

This implements caching via Redis using django-redis. This officially makes Redis required for NetBox.
I also implemented basic support for django-prometheus because I strongly feel that with the addition of caching, we need to provide more visibility into application performance. This will also aid in development down the road.
This still needs to have docs writen for caching in general and the new configuration settings.
As for review, much of this is rather boring; the only real meat here is in settings.py.

I also implemented basic support for django-prometheus

How is this related to caching? This would need to have its own issue, discussion, and separate PR.

psycopg2.OperationalError: FATAL:  database "netbox" does not exist

That's a new one. Come on, Travis, get it together.

authors: jeremystretch lampwins


text:
change cacheing to use cacheops

Fixes: #2647
Changed caching mechanism to use django-cacheops which has native support for queryset caching and automatic invalidation built in.

LGTM :+1: I'll let you decide when to merge; not sure if you were still working on something for invalidation logic.


text:
🛑 android-7.1.2_r39 is down

In ffbd252, android-7.1.2_r39 (http://aospxref.com/android-7.1.2_r39/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: android-7.1.2_r39 is back up in a4558e5 after 12 minutes.

repo: dimenspace/aosp-uptime


text:
Problem setting focus input in a popup

http://jsfiddle.net/PUxJ4/
I have a problem setting focus input in a popup. Once a popup opens, the focus is seen in the input field for a second or so, after which it immediately disappears. Please advise.

Hi dimsemenov,
Magnific Popup - v1.1.0
I set
$('#search_btn').magnificPopup({
type: 'inline',
preloader: false,
focus: '#search_input'
});
But can not focus to  in Safari Iphone. But it work well on Chrome  Android .

Trying to set the focus on the close button when the window opens. Using image as type. Have id on the button called #setFocus and then the focus property set to #setFocus. Any help would be appreciated.

authors: bradleymyers sksdes vuongngoquoc

repo: dimsemenov/Magnific-Popup


text:
On Windows, getcontext returns an error

It seems that getcontext returns a error and it's impossible for pth to spawn a new thread. Due to this error, a SEGFAULT is reached at one point where no threads was launched but pth_key_setdata expects a current one. I will try to find if the error come from Cosmopolitan or if it's a real barrier.

It seems not possible to use pth on Windows (it seems that only w32 is supported). More concretely, Cosmopolitan does not implement

mcsc machine context method (makecontext(3)/setcontext(3)) for Windows (ESYS is returned)
sas stack setup method (sigaltstack(2))
ss stack setup method (sigstack(2))

sjljw32 is available but it works only for a 32-bits architecture which is too restrictive for us. We have 2 ways to solve this issue:

implement required functions mcsc, sas or ss into Cosmopolitan
modify pth to provide a Windows implementation of pth_mctx - we probably need to use the mcsc compilation path and check if we are into IsWindows() and do something else than makecontext/setcontext

The required interface of pth_mctx is:
typedef struct pth_mctx_t pth_mctx_t;

pth_mctx_switch(pth_mctx_t* , pth_mctx_t *);
pth_mctx_restore(pth_mctx_t *);
pth_mctx_set(pth_mctx_t *, void (*f)(void), char *addr_lo, char *addr_hi);

@dinosaure Cosmopolitan Libc has pthreads support now. https://github.com/jart/cosmopolitan/releases/tag/2.1 If there's an issue with setcontext() and getcontext() that are causing issues for fibers, then let me know and I'll fix it.

Thanks @jart, I will probably focus on that in 2~3 weeks :+1: - It's currently on top of my TODO list.

Awesome to hear! Looking forward to seeing where it goes.

FIxed by #28 which uses Cosmopolitan 2.2 (which has pthread_ functions).

authors: dinosaure jart

repo: dinosaure/esperanto


text:
Fixing walk() example to match output.

Interesting project  :-)
Hope you are well friend.

Hi, thanks for your patch :) Actually, .range(10, 12) should return a stream containing [10, 11, 12] – it ranges from 10 to 12. Similarly .range(0, 10) should include the numbers from 0 to 10. Can you verify that it works? Thanks!

Ha!  Should have read it better :-)

Can you verify that it works?

Yes, it works  :-)

authors: dionyziz jonathancross


text:
Fix memory leak in known_folder()

The documentation for SHGetKnownFolderPath states:

The calling process is responsible for freeing this resource once it
is no longer needed by calling CoTaskMemFree, whether
SHGetKnownFolderPath succeeds or not.

Currently the known_folder() function only calls CoTaskMemFree when
SHGetKnownFolderPath returns S_OK, causing a memory leak whenever
SHGetKnownFolderPath fails.
References:
https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderpath

Thanks, great catch!

authors: lberrymage soc

repo: dirs-dev/dirs-sys-rs


text:
possible to have timeout and cancel prompt edit the last start or retry?

I'm currently using
prompt: {
    modifyStart: (message, text) => {
        return `${text}\n\`Type exit to cancel this command.\``;
    },
    cancelWord: 'exit',
    cancel: 'Command has been cancelled.',
}

in my commandHandler and when i type exit to cancel the command it creates a new message saying the command has been canceled or when the message times out it puts a new message saying the command has been canceled. Can I make it where instead of creating a new message it edits the last message instead? I feel it'd be much cleaner and remove some confusion compared to when the prompt question is still visible.

As far as I'm aware, there is currently no way to do this. If you really want it you can make a pr following the template.

Ah.. okay, yeah I don't even know where to begin on how to implement that. but alright, thanks.

authors: TitusEntertainment zfbx

repo: discord-akairo/discord-akairo


text:
Missing translation: https://reactjs.org/docs/static-type-checking.html

static type checking part are missing in Chinese doc.
missing part: https://reactjs.org/docs/static-type-checking.html

感谢提醒，已添加

authors: ChenXiyu discountry

repo: discountry/react


text:
[New API] : Book Management API

Brief Description 🤓
A Book Management API is a web service that allows users to manage a collection of books. This type of API provides endpoints for performing CRUD (Create, Read, Update, Delete) operations on a database of books.
Features:

One can use this api to keep track of personal books they own in their shelf or library or book store.
You can add, delete, update the book details.
Authentication : For a more secure API,  authentication will be implemented  via JWT tokens.
Error Handling: To manage scenarios like invalid inputs, non-existent book IDs, or database connection issues, error handling will be implemented.

How will you develop it?🤩
I will built it using Node.js, Express and Postman
Endpoints:

GET /users: Retrieve all users.
GET /users/{id}: Retrieve user by ID.
POST /users: Add a new user.
PUT /users/{id}: Update a user by ID.
DELETE /users/{id}: Delete a user by ID.
GET /books: Retrieve all books.
GET /books/{id}: Retrieve a specific book by ID.
POST /books: Add a new book.
PUT /books/{id}: Update a book by ID.
DELETE /books/{id}: Delete a book by ID.

Deployment
None
Select the open source program you are contributing to
Other
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINES of this project.

Greetings @its-kritika🎀 ! , We are excited to have you dive into another issue with us!🚀
Your involvement in our project has been invaluable, and we're confident that your skills and insights will help us conquer this challenge😇.  Use command /gssoc24 to self assign the issue.  This issue represents an exciting opportunity for us to improve and enhance our project, and we are thrilled to have you on board.
We request you to follow CONTRIBUTING GUIDELINES.
Looking for your PR soon!
In case of any issues, you can contact us on Discord.❣

/gssoc24

Hey @its-kritika ! I wanted to inform you that we have closed issue.Thank you for your understanding, and we look forward to your continued engagement with our repository🤗.
In case of any issues, you can contact us on Discord.
Thank you! ❣
Happy Coding! ✨
Will See you soon❣


text:
Support DITA 1.3 branch profiling

DITA 1.3 proposal 13059a.
Add support for branch filtering.

Initial implementation via #1969

repo: dita-ot/dita-ot


text:
Android: Add in-app save import/export

Not everyone can or is willing to enable ADB debugging (ie. they are not technically savvy, or they are using a locked down custom ROM such as CalyxOS), so an in-app menu option to import and export a save file would be nice.

Exporting a save file seems easy enough. Need to think about how to design importing one. Can I safely invoke a file picker from the game? Or can the game become a target to receive "send to"? Not quite sure about that part yet.

repo: divVerent/aaaaxy


text:
Renamed copy/pasting/updating events

In the past we were using namespaced events for moving/pasting and
updating structureboard events. Due to the nature of jQuery events
namespaces cms.update event could trigger cms.plugins.update
where it wasn't required, which in turn led to incorrect tree when
pasting plugins. This pr replaces custom events to be unique
strings so they don't interfere with each other.
This is a forwardport of https://github.com/divio/django-cms/pull/5484

Coverage increased (+0.9%) to 89.563% when pulling 6c9e834b406c5a9117e29736f0f698d2a228ce04 on vxsx:bugfix/copy-pasting-plugins-forwardport into 48adc2c7a74f5089ad122db518f6ced41b20af16 on divio:develop.

Coverage increased (+0.9%) to 89.563% when pulling ddcd2308a8495833e90999979ef3392c9c9a1b66 on vxsx:bugfix/copy-pasting-plugins-forwardport into d735c4554fdc896898807d43ca6512ffd4377397 on divio:develop.

authors: coveralls vxsx

repo: divio/django-cms